#295 Collective-scoped auth keys + OIDC federation for CI publishing

Problem

Today, swamp extension push authenticates with an API key tied to a user account. swamp auth whoami confirms this — the apiKey field maps to a single user (apiKeyId is just a label).

This is operationally fragile when a collective (e.g. @hivemq, @swamp) wants to publish extensions from CI:

1. Personal key in shared CI. Whoever mints the key has their personal credential sitting in a GitHub Actions secret. If they leave the org, rotate their personal token, or lose access, every CI publish silently breaks.
2. No principle of least privilege. A user key carries the publishing rights of every collective that user belongs to. We can't scope a CI key to "only @hivemq" — if the user is also in @borg and @bixu, the key transitively grants those too.
3. Long-lived secret in repo settings. GitHub Actions secrets are durable, hard to rotate cleanly, and can leak via misconfigured workflows or compromised actions.

Proposed solution

Two related additions, ordered by impact:

1. Collective-scoped API keys

Allow minting an API key whose principal is a collective, not a user. Key minting requires the user to currently be a maintainer of that collective; the resulting key is owned by the collective and survives membership changes. Scope is bounded to that collective's namespace — @hivemq/*, nothing else.

swamp auth key create --collective hivemq --name "github-actions-publish"
# returns: hc_xxx (collective-scoped, can only push @hivemq/*)

Other maintainers of the collective can list/rotate/revoke the key.

2. OIDC federation (ideal end state)

Eliminate the long-lived secret entirely. Mirror the pattern AWS/GCP/Azure already support for GitHub Actions:

1. Collective owner registers a trust policy on swamp.club, e.g.

   collective: hivemq
   issuer: https://token.actions.githubusercontent.com
   sub: repo:hivemq/swamp-extensions:ref:refs/heads/main

2. CI workflow requests an OIDC token via id-token: write.
3. swamp auth federate --oidc-token "$OIDC_TOKEN" exchanges it for a short-lived (e.g. 15-minute) credential scoped to the collective.
4. swamp extension push uses that credential — no static secrets in repo settings.

Reference for the pattern: GitHub's OIDC integration guide and AWS's configure-aws-credentials action.

Why now

We just hit a publish hang against swamp.club that ran for 6 hours before GitHub's max-execution timeout killed it (hivemq/swamp-extensions run 25510761754). The fix involves a swamp auth whoami cred check on PRs — but that check is meaningful only because the credential is a personal user key that can go bad in ways that don't reflect the collective's intent. Federated, collective-scoped credentials would make most of that defensive plumbing unnecessary.

Alternatives considered

• Service-account user. Mint a "fake" user (hivemq-ci) and use its key. Works today, but is a workaround — service accounts in swamp aren't a first-class concept, and the key still has all the rotation/least-privilege problems above.
• Signed manifest uploads. Sign manifests with a collective-owned keypair, no API key needed for push. More invasive on the protocol side; OIDC federation is the same idea with established infrastructure.