Spec: upgrade AMS's predicted-gate to query ORB's live self-tuned config when both are installed

[JSONbored]

Problem

packages/loopover-miner/lib/self-review-context.js predicts a gate verdict by reconstructing the target repo's policy from its static .loopover.yml file (read directly off GitHub) plus defaults — this is the correct, necessary fallback for a repo where ORB isn't installed at all. But when ORB genuinely is installed and actively running on the target repo, that static reconstruction ignores real, live information ORB already has: src/review/auto-apply.ts's self-tune loop maintains live-tuned gate thresholds (via tunables_overrides/_shadow D1 tables, migrations/0047_self_improve_tunables.sql) that can differ from what a static .loopover.yml alone would predict. A miner working against an ORB-active repo is currently getting a less accurate prediction than the repo's own live gate would give.

Area

packages/loopover-miner/lib/self-review-context.js (AMS), src/review/auto-apply.ts + the self-tune D1 tables (ORB), src/api/routes.ts (wherever a new read-only endpoint would need to live).

Proposal (open questions a design pass needs to answer — not yet decided)

• Detection: how does AMS know ORB is actually installed and active on the target repo, versus just having a stray .loopover.yml committed with no live App installed? A live-probe HTTP call (e.g. a lightweight /v1/repos/:owner/:repo/status ping) is one option; consider whether this should reuse the same isMcpReadRepoAllowed-style gating this session's audit found on other MCP-facing routes (#6154's reviewability tool).
• Data exposure: exactly which fields from ORB's live self-tuned config are safe to expose to an external caller (a miner who may not be a repo collaborator)? This must not leak anything submitter-reputation.ts/auto-apply.ts currently treat as strictly internal — likely only the effective thresholds, never raw audit/override history.
• Fallback behavior: if the live-probe fails or ORB isn't present, AMS must fall back to today's static-file reconstruction with zero behavior change — this is additive-only.
• Auth: does this need a new, narrower-scoped read path than the full resolveGitHubToken session flow, since it's reading repo-level gate config, not acting as the user's own GitHub identity?

Deliverables

• A decided design: detection mechanism, exposed field allowlist, auth/access model, and confirmed fallback behavior.
• A written spec that a future contributor-open implementation issue (both the ORB-side read endpoint and the AMS-side consumer) can be scoped from.

Resources

• packages/loopover-miner/lib/self-review-context.js (today's static-file fallback, to be preserved)
• src/review/auto-apply.ts, migrations/0047_self_improve_tunables.sql (the live self-tuned config this would expose)
• #6154 (a related MCP-auth-aware route pattern found this session, useful precedent for the access-control shape)

Boundaries

• maintainer-only until the exposed-field allowlist and auth model are decided — this touches what's safe to reveal about a repo's live, possibly-tuned-in-response-to-abuse gate config to an external caller.
• Must remain purely additive: AMS's standalone (ORB-absent) prediction path must not change at all.
• No exposure of raw override-audit history, submitter-reputation data, or anything else auto-apply.ts/submitter-reputation.ts treat as internal-only.

[linear-code]

JSO-4311