Generalize src/orb/broker.ts into a multi-secret-type broker shared by ORB + AMS hosted

[JSONbored]

Problem

src/orb/broker.ts already solves "prove installation ownership, then mint/cache a short-lived secret" — but it's GitHub-token-specific as written: orb_enrollments has no secret_type/kind column, brokerOrbToken's return shape is hardcoded to GitHub's { token, expiresAt, permissions }, and the mint call is GitHub's installation-token endpoint specifically (confirmed by direct code read). Hosted ORB and AMS both need to broker more than GitHub tokens — AI-provider keys at minimum, DB credentials once #7173's storage migration lands.

Area

src/orb/broker.ts, src/orb/oauth.ts, migrations/ (new column on orb_enrollments or a new table).

Proposal

Add a secret_type discriminator and a pluggable per-type mint/refresh strategy, keeping the parts that are already generic unchanged: the admin-ownership proof (verifyInstallationAdmin), the opaque-secret issuance + hash-storage pattern (createOpaqueToken/hashToken), and the AES-256-GCM cache encryption (encryptSecret/decryptSecret) all carry over as-is. Only the mint/refresh call and the returned shape need to become type-aware.

Deliverables

• secret_type column on orb_enrollments (or equivalent), migration included
• A mint/refresh strategy interface, GitHub-token as the first (already-working) implementation
• An AI-provider-key strategy implementation
• Existing GitHub-token brokering behavior unchanged — this is additive, not a rewrite

Boundaries

• Secrets custody design touches every tenant's blast radius — maintainer-only, no partial/contributor-drafted version merged ahead of full review (same bar Design: centralized secrets custody for AI-provider keys and DB credentials across hosted AMS tenants #5225 and Add per-tenant namespacing to secret resolution #4921 were already held to).
• Does not itself decide the hosted secrets-manager binding (Add a KV/Vault/secrets-manager binding #4923) — this generalizes the existing brokering mechanism; Add a KV/Vault/secrets-manager binding #4923 is about the underlying storage substrate.

Links & Resources

• Design: shared hosting control-plane for ORB + AMS SaaS (provisioning, secrets, billing, health) #7173 (parent — shared hosting control-plane)
• src/orb/broker.ts, src/orb/oauth.ts, src/orb/app-auth.ts
• Design centralized custody for AI-provider keys #4922 (AI-provider key custody design — likely resolved by this), Add a KV/Vault/secrets-manager binding #4923, Add per-tenant namespacing to secret resolution #4921, Design: centralized secrets custody for AI-provider keys and DB credentials across hosted AMS tenants #5225 — related secrets issues on both products, should reference this once it lands

[linear-code]

JSO-4932