feat: multi-org / multi-GCP-project support

[jackvaughanjr]

Summary

Allow snipemgr.yaml to configure multiple GCP projects and/or registry sources, enabling management of integrations across multiple environments (prod/staging) or multiple clients from a single config.

Motivation

As the integration suite matures, some users will want to:

• Run the same integrations in both a staging and production GCP project
• Source integrations from a trusted partner org's registry alongside the default
• Manage multiple clients' Snipe-IT instances from one place

Configuration

registry:
  sources:
    - owner: jackvaughanjr            # default — official integrations
    - owner: some-partner-org         # explicitly trusted external source

environments:
  production:
    gcp_project: my-org-prod
    snipeit_url: https://snipeit.example.com
  staging:
    gcp_project: my-org-staging
    snipeit_url: https://snipeit-staging.example.com

CLI changes

snipemgr status --env production
snipemgr run github2snipe --env staging
snipemgr install github2snipe --env production

When --env is omitted, commands use the default environment (first defined, or one marked default: true).

Acceptance criteria

• Multiple registry.sources are supported — integrations from all sources appear in snipemgr list
• Source provenance is shown in list output (e.g. [partner-org] prefix)
• Multiple environments can be defined in snipemgr.yaml
• --env <name> flag on all commands selects the target environment
• State file tracks which environment each integration is installed in
• snipemgr doctor checks each configured environment independently
• Single-environment configs (current format) continue to work without changes

Implementation notes

• This is a significant config schema change — version the config format and provide a migration path
• External registry sources should be treated with appropriate caution — document the trust model clearly
• State file needs to partition entries by environment to avoid name collisions