feat(review): add a read-only endpoint exposing ORB's live self-tuned gate thresholds

[galuis116]

Closes #6486

Summary

#6209 decided the design (see its pinned decision comment): AMS probes a new read-only ORB endpoint for a repo's live self-tuned gate thresholds before falling back to static-file reconstruction (the AMS-side consumer is a separate, blocked-on-this sibling issue, #6487). This PR is the ORB-side endpoint only.

New GET /v1/repos/:owner/:repo/live-gate-thresholds:

• Field allowlist is exact, per Spec: upgrade AMS's predicted-gate to query ORB's live self-tuned config when both are installed #6209's decision: only confidence_floor, scope_cap_files, scope_cap_lines — no applied_at/clear_at, no override_audit history. These are the live TunableOverride fields already defined in src/review/auto-apply.ts.
• Live wins; a soaking shadow fills in when live is absent — Spec: upgrade AMS's predicted-gate to query ORB's live self-tuned config when both are installed #6209's decision explicitly wants AMS to see a pending tightening too, not just an already-promoted one.
• 404 with { error: "live_gate_thresholds_not_found", repoFullName } when neither a live nor a shadow override is active — matching the existing not-found convention /issue-quality's route already uses (issue_quality_not_found), per the issue's own "follow existing convention, don't invent a new response shape" requirement.
• Auth: isMcpReadRepoAllowed + MCP_READ_REPO_ALLOWLIST gates a static mcp-actor identity; every other identity (an authenticated session, or an operator-only static token) is trusted — the exact same gate already used on src/api/routes.ts:2354/2368/2959. This is deliberately the simpler pattern, not the stricter requireStaticProtectedApiToken-gated shape the sibling /gate-config/effective route (feat(review): add a read-only endpoint exposing ORB's live self-tuned gate thresholds for a repo #6247) uses — Spec: upgrade AMS's predicted-gate to query ORB's live self-tuned config when both are installed #6209's decision comment names this specific gate ("the exact same gate already used on ~6 existing MCP-facing read routes"), and /gate-config/effective predates Spec: upgrade AMS's predicted-gate to query ORB's live self-tuned config when both are installed #6209's decision and has a different (nested camelCase, shadowPending-flagged) response shape serving a different UI consumer, so this is intentionally a distinct route, not a duplicate.

Two new pure helpers in auto-apply.ts:

• authoritativeGateOverride(live, shadow): live ?? shadow?.override ?? null — live wins, shadow is the fallback.
• toLiveGateThresholdFields(override): projects into the exact snake_case allowlist, returning null when the override carries neither a confidenceFloor nor a scopeCap.

Note on a prior closed attempt

A previous PR for this issue (#6545) was auto-closed on codecov/patch failing at 95.45% (1 uncovered line). I did not blindly reuse that PR's diff — I re-derived the implementation from #6209's decision comment and the existing precedent routes, then wrote my own test suite and specifically traced every branch by hand before writing tests, including the exact combination that's easy to miss in a ??-heavy projection function (a confidenceFloor-absent-but-scopeCap-present override, and vice versa — see toLiveGateThresholdFields's 5 dedicated unit tests). I also caught and removed a v8 ignore comment I'd initially misattributed to the wrong line while drafting (copied from an adjacent "unauthenticated requests never reach here" precedent that doesn't actually apply to the mcp-allowlist check) — verified via lcov line/branch hit-count output that the real conditional is genuinely, fully exercised by the test suite with no coverage exemption needed at all.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves — Closes feat(review): read-only endpoint exposing ORB's live self-tuned gate thresholds #6486.

Validation

• git diff --check
• npm run actionlint
• npm run db:migrations:check / db:schema-drift:check — N/A, no migration or schema change (reuses the existing tunables_overrides/tunables_overrides_shadow tables as-is).
• npm run selfhost:env-reference:check / selfhost:validate-observability
• npm run docs:drift-check / manifest:drift-check / command-reference:check
• npm run ui:openapi (regenerated) / npm run ui:openapi:check (clean) / npm run ui:openapi:settings-parity (clean) — new LiveGateThresholdsResponseSchema + path registered in src/openapi/schemas.ts/spec.ts, apps/loopover-ui/public/openapi.json regenerated and committed.
• test/unit/auto-apply.test.ts (full file, 103 tests) and test/integration/api.test.ts (full file, 48 tests) — both 100% passing.
• Broader regression sweep: auto-apply/auto-tune/reputation-wiring test files together — 190 tests, all passing.
• Coverage verified directly, not assumed: ran a scoped vitest --coverage against just src/review/auto-apply.ts and src/api/routes.ts with only my 2 changed test files. auto-apply.ts — 100% statements/functions/lines, 98.72% branch with the single remaining gap confirmed pre-existing and unrelated (runAutoApplyRecommendations, an untouched function, in a partial 2-file run — the full suite covers it). My new route's exact lines, verified via the lcov report's per-line DA:/BRDA: hit counts: every line has a non-zero hit count, and both sides of every branch (the identity?.kind === "static" && identity.actor === "mcp" && !isMcpReadRepoAllowed(...) chain, and the if (!fields) 404 check) show non-zero counts on both outcomes.
• npm audit --audit-level=moderate — 0 vulnerabilities.
• Root npm run typecheck / unsharded npm run test:coverage — this sandbox's root tsc --noEmit reliably OOMs regardless of diff content (reproduced repeatedly this session, confirmed again on this diff — the failure trace shows the standard V8 heap-limit abort, not a real type error). Substituted with careful manual type review of every new line (documented above) plus npm run ui:openapi's own tsx-driven type-check of the new Zod schemas passing clean, plus the scoped coverage run's line-by-line confirmation that the actual runtime code paths execute exactly as written.

If any required check was skipped, explain why:

• Root typecheck/unsharded test:coverage: established OOM pattern in this sandbox (2.3GB free RAM, no swap headroom), unrelated to diff content. Substituted with the scoped, file-targeted coverage verification above, which is the specific signal Codecov's codecov/patch gate actually measures for this diff.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. — Not an auth-model change (reuses the existing isMcpReadRepoAllowed gate verbatim), but the negative path (403 forbidden_repo, 401 unauthenticated) is explicitly tested in the integration test.
• API/OpenAPI/MCP behavior is updated and tested where needed. — New route, schema, and path registered; ui:openapi:check clean.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. — N/A, no UI change.
• Visible UI changes include a UI Evidence section below with screenshots. — N/A, no UI change.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. — CHANGELOG.md untouched.

Notes

The AMS-side consumer (self-review-context.js probing this endpoint, #6487) is explicitly a separate, blocked-on-this sibling issue and is not built here.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[galuis116]

Closing — #6486 was independently resolved by #6553, which merged first. No need to carry two implementations of the same endpoint.