Research spike: auth/identity provider comparison for hosted AMS

[JSONbored]

Problem

AMS has no auth/identity layer today — self-host is single-operator, single-machine, with no login concept at all. A future hosted AMS needs one, but no survey of viable approaches (managed auth provider vs. custom JWT/OIDC) has been done, so the eventual auth design issue would otherwise start from scratch.

Area

AMS / Cloud architecture

Proposal

Survey and document realistic options (e.g. a managed identity provider vs. a custom token-based scheme) evaluated against AMS's existing installation-token / GitHub App patterns already used by ORB's broker (src/orb/broker.ts), so the eventual auth/identity design issue starts from an informed baseline that's consistent with infrastructure gittensory already operates, rather than proposing an unrelated auth stack.

Deliverables

• A comparison document covering at least 2-3 approaches with security and integration tradeoffs
• Explicit notes on how each option would interact with ORB's existing installation-token exchange pattern (reuse vs. replace vs. run alongside)

Resources

• src/orb/broker.ts, broker-client.ts (existing token-exchange precedent)
• packages/gittensory-miner (current no-auth, single-operator model, for baseline contrast)

Boundaries

• Research and writeup only — this issue must NOT implement any auth flow, token exchange, or identity-provider integration, and must NOT decide the auth model.
• The actual auth/identity layer design remains a separate, maintainer-only issue once this comparison lands — this issue's output is an input to that decision, not the decision itself.
• Must NOT propose changes to src/orb/broker.ts's existing token-exchange behavior; it is documented here strictly as precedent to compare against.

[linear-code]

JSO-3743