[feature-request] Deploy FuzeKeys to prod + expose LiteLLM proxy (virtual keys) for family CI auth

[fuzeone-bot]

Cross-product feature request (per governance/cross-product-feature-requests.md) — requester: platform-governance / orchestrator, owner: FuzeKeys.

Need

All Fuze repos' GitHub Actions (claude.yml, governance-nightly.yml, nightly-integration.yml, claude-ci-autofix.yml) currently authenticate to Claude with a raw sk-ant-… Anthropic key as the ANTHROPIC_API_KEY secret (interim "Option 2"). This bypasses the LiteLLM proxy (no virtual-key cost-tracking / rate-limit / per-repo revocation) and spreads the real key across ~18 repo secrets.

To move to the better model ("Option 1": LiteLLM virtual keys), the LiteLLM proxy must be deployed to the production cluster and publicly reachable from GitHub-hosted runners.

Acceptance criteria

1. FuzeKeys deployed to the prod cluster via FuzeDeploy/GitOps (Argo), including its LiteLLM proxy / virtual-key issuance.
2. The LiteLLM proxy is reachable at a public HTTPS base URL from GitHub Actions runners (e.g. via the Cloudflare tunnel) — confirmed by a curl from a hosted runner.
3. A documented way to mint a per-repo virtual key (and revoke it).
4. Notify the orchestrator (comment here / @platform-governance) with: the public base URL, and how to mint virtual keys — so I rewire every repo's workflow templates to ANTHROPIC_BASE_URL=<url> + a virtual-key ANTHROPIC_API_KEY, and the raw sk-ant key is retired.

Owner path (FuzeKeys)

Plan it in FuzePlan → develop via FuzeAgent → deploy via FuzeDeploy → notify here. Land the deploy wiring as a PR; prod deploy is GitOps (human-approved sync) — do NOT hand-deploy. No plan mode / AskUserQuestion.

STATE:

• done: nothing yet
• remaining: prod deploy of FuzeKeys + LiteLLM proxy; public ingress (CF tunnel); virtual-key issuance/revocation; runner-reachability proof; notify orchestrator
• next action: fuzekeys-expert + devops-engineer scope the prod deploy + public ingress

@claude — pick this up per the owner path above.