fix(review): velocity-aware exception in the unlinked-issue-match escalation for machine-cadence (miner) authors

[JSONbored]

Context

A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that the unlinked-issue credibility-farming guardrail's repeat-escalation rule is calibrated for human abuse cadence and produces the wrong outcome under machine cadence.

Evidence

• src/review/unlinked-issue-guardrail.ts:22-25 — a 90-day repeat window ("a match from a year ago shouldn't silently escalate... forever").
• src/review/unlinked-issue-guardrail.ts:52-55,76-127 — hasPriorUnlinkedIssueMatch is keyed only by authorLogin and correlated across any repo in the install; the first match holds the PR, a confirmed repeat within the window escalates straight to auto-close (lines 113-119).
• src/db/repositories.ts:2609-2617 — hasRecentAuditEventForOtherTarget confirms the cross-repo, no-repo-scoping correlation.
• Issue feat(review): guard against credibility gate farming via unlinked-issue PRs #3555's own design rationale (the guardrail's origin issue) is written purely in terms of a human being unlikely to repeat the same "forgot to link the issue" mistake twice in 90 days — it never considers a bot/miner author.

Why this matters for the Autonomous Miner System

A systematic bug in how a miner auto-generates its PR body (e.g., a template that occasionally omits Closes #N even though it correctly solved a real, ranked issue) could recur within hours rather than months at machine cadence. Because the correlation key is author login across all repos in the install, a miner fleet's very first two legitimate PRs system-wide could trigger hold-then-close, converting one tooling bug into cross-repo closure of otherwise-correct, properly-targeted work — with no cadence-aware distinction between deliberate farming and a fast, legitimate miner repeatedly hitting its own formatting defect. The guardrail is opt-in per repo (mode: off by default), which bounds blast radius somewhat, but the core failure mode reproduces within a single opted-in repo with no cross-repo amplification needed.

Deliverables

• Add a velocity/cadence-aware exception to the repeat-escalation path: e.g. require a minimum time gap between the first hold and the confirmed repeat before escalating to auto-close, or cap escalation severity (hold again, rather than close) when both matches occur within an implausibly short human window
• Ensure the exception can't be trivially exploited to launder repeated deliberate abuse (the fix should distinguish "two legitimate fast submissions" from "rapid-fire farming," not just widen the window uniformly)
• Tests: same-day repeat from a confirmed_miner author does not straight-close; a slow, spaced-out human repeat still escalates as today; adversarial case (rapid genuinely-farming repeats) still escalates
• Docs: note the cadence exception in the guardrail's own config documentation

---

Surfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Related: #3555 (the guardrail's origin issue), #2346 (miner-side self-reputation throttle), #2350 (fleet-wide anti-farming detector) — all address adjacent but distinct risk surfaces.

[linear-code]

JSO-3356