fix(github): complete budget attribution for rate-limit admission

[JSONbored]

Parent: #1936

Problem

Recent live behavior shows the queue can become intentionally parked by GitHub rate-limit admission. That is safer than retry storms, but beta-stable requires knowing exactly which actor, job type, and endpoint class is consuming budget.

Requirements

• Every GitHub REST and GraphQL call path should have stable budget attribution where possible.
• Persisted observations should distinguish installation, brokered/global, repo fallback, and unknown/public buckets.
• Admission decisions should not be confused by legacy/null observations once keyed observations exist.
• Metrics and logs must make the root cause visible without SSHing into SQLite.

Deliverables

• Audit all GitHub API call paths for admission key/rate observation coverage.
• Add missing labels/structured fields for job type, trigger kind, endpoint class, token scope, and installation/broker scope without high-cardinality labels.
• Add dashboard panels or alert text that explains parked queue states.
• Add tests for attribution invariants and legacy observation fallback behavior.

Acceptance criteria

• A dashboard can answer: which queue job type is blocked, which budget bucket is low, and when it should resume.
• Unknown/global observations do not incorrectly mask or override newer exact-key observations.
• Repo-scoped jobs still honor relevant token-wide exhaustion.
• No new high-cardinality Prometheus labels are introduced.

Expected outcome

Rate-limit incidents become diagnosable from metrics and logs, and admission behavior stays correct across migrations and multi-repo installations.

[linear-code]

JSO-2025

[JSONbored]

Analysis input — two attribution gaps found

1. GraphQL calls bypass admission + attribution entirely. githubGraphQl (src/github/backfill.ts:2894-2918) records the response via recordGitHubResponse(env, null, "/graphql", response, "graphql") — passing null as the admission key. So every GraphQL call (repo totals, PR details, review threads, reviewDecision, and — after #1941 — the status rollup) is invisible to REST admission and to the key_scope attribution buckets. GraphQL has its own points bucket, but it still counts toward App-wide secondary limits, and #1941 will move the entire CI hot path onto it — so it needs first-class attribution (installation vs brokered/global vs repo-fallback) and its own admission observation, or the dashboards will show REST pressure dropping while GraphQL pressure is untracked.

2. Attribution key coverage. The REST path keys observations via the admission key (src/github/client.ts:131-148, githubAdmissionKeyScope → installation / global / other). Worth auditing that: (a) the brokered-mint calls in src/orb/app-auth.ts:42-66 (App-JWT GET /app/installations, POST .../access_tokens) carry a distinct broker/global scope so brokered pressure is separable from a self-hoster's own installation pressure; and (b) legacy null observations don't mask newer keyed ones (the acceptance criterion here) — latestGitHubRestRateLimitObservation is keyed by admission key, so a null-keyed GraphQL observation and an installation:*-keyed REST observation live in separate map slots, which is correct, but means GraphQL exhaustion is currently unobservable.

Both are cheap to wire and directly serve this issue's "identify whether pressure comes from webhooks, background regates, status reads, brokered calls" goal — GraphQL/status-rollup pressure is currently a blind spot.