Resolve dead aiReviewCloseConfidence floor (decision + fix)

[JSONbored]

Context

Part of the review-stack architecture audit (parent epic).

Root cause (git-blame confirmed): commit 311b7613d ("fix(review): enforce blocker-first PR
verdicts (#1781)", 2026-06-29) intentionally removed the old isLowConfidenceAiReviewHold mechanism, so
an ai_consensus_defect / ai_review_split finding now hard-blocks unconditionally whenever
aiReviewGateMode: "block", regardless of the model's own confidence. The commit correctly rewrote
one docstring (src/types.ts:832-836, the RepositorySettings.aiReviewCloseConfidence field) to say
the floor is now "retained as configurable context, not a manual-review downgrade" — but left five
other copies of the old claim unedited, scattered across the exact code path that produces and carries
the value:

Location	Stale claim
src/types.ts:457-461 (AdvisoryFinding.confidence)	"an AI defect blocks ONLY when this clears the floor"
src/services/ai-review.ts:395-398 (ModelReview.confidence)	"Drives the gate's aiReviewCloseConfidence floor"
src/services/ai-review.ts:1423-1426 (consensusDefectOf)	"the calibrated confidence (#8) ADDS a numeric floor on top"
src/services/ai-review.ts:2207-2209 (runGittensoryAiReview return)	"gate ai_review_split on the same floor as a consensus defect"
src/queue/processors.ts:7589,7604-7607	"clears aiReviewCloseConfidence ⇒ block; below it ⇒ human-review hold"

The actual gate code, isConfiguredGateBlocker (src/rules/advisory.ts:882-886):

if (code === "ai_consensus_defect" || code === "ai_review_split") {
  void (policy.aiReviewCloseConfidence ?? DEFAULT_AI_REVIEW_CLOSE_CONFIDENCE);
  return gateMode(policy.aiReviewGateMode ?? "advisory") === "block";
}

literally voids the confidence value and returns based on aiReviewGateMode alone.
finding.confidence is never read anywhere else in the gate path to decide block-vs-hold — it is now
pure telemetry.

Concrete failure scenario

Repo has gate.aiReview.mode: block (documented closeConfidence default 0.93). Two independent AI
reviewers both flag the same ambiguous line as a blocker but each self-report low confidence (0.3-0.4) —
consensusDefectOf sets confidence: Math.min(a.confidence, b.confidence) exactly as designed. Per
every one of the five stale comments, a sub-0.93 confidence should degrade this to a neutral
"held for human review." Instead the PR is auto-CLOSED one-shot (contributor PRs are one-shot). This is
also user-facing config-as-code — .gittensory.yml.example:346-351's comment (correctly, unlike the
internal docs) already says the floor no longer downgrades a blocker, so a maintainer tuning
closeConfidence today is tuning a no-op.

This issue needs a decision before code changes

Two valid resolutions — pick one before implementing:

1. The post-fix(review): enforce blocker-first PR verdicts #1781 behavior (confidence is pure telemetry, no downgrade) is intentional → fix the 5 stale
   comments to match src/types.ts:832-836's already-correct language. No behavior change.
2. The confidence floor should still downgrade low-confidence consensus defects to a hold →
   restore the comparison in isConfiguredGateBlocker, matching what all 5 comments (and the
   closeConfidence config field's continued existence) still promise callers.

Acceptance criteria

• Decision made and recorded in the PR description (which of the two resolutions, and why).
• All 6 locations (the 5 stale comments + isConfiguredGateBlocker if behavior changes) are
  consistent with each other.
• If behavior changes: regression test proving a sub-floor consensus defect degrades to hold, not
  close.

[linear-code]

JSO-3386

[JSONbored]

Decision (resolved — implement against this, do not re-litigate)

Confidence should not gate whether an AI-consensus defect counts as a blocker (that's what
aiReviewGateMode already does) — it should gate whether a triggered blocker is safe to act on
irreversibly, without a human in the loop. A blocker can be real and still not be a case the
system should one-shot-close on its own judgment.

New field: aiReviewLowConfidenceDisposition: "one_shot" | "hold_for_review" | "advisory_only"

Governs what happens when an ai_consensus_defect / ai_review_split finding's confidence is
below aiReviewCloseConfidence (the existing floor field, unchanged):

• one_shot — today's live behavior, unchanged: confidence is ignored, the defect always
  one-shot-closes when aiReviewGateMode: "block". Opt-in only, for maintainers who want max
  automation and accept the false-positive risk.
• hold_for_review (shipped default — flips today's silent behavior back to safe) — the
  defect still blocks the merge (gate still fails, contributor still can't merge as-is), but does
  not one-shot-close. Route it through the same "held for human review" mechanism the planner
  already uses for unlinkedIssueMatchHold/migrationCollisionHold in
  src/settings/agent-actions.ts — reuse that existing hold path, don't invent a second one.
• advisory_only — below the floor, the finding drops to fully non-blocking advisory. For
  maintainers who'd rather lean on other deterministic gates and never see a review-hold queue.

Global default + per-repo .gittensory.yml override, resolved through the normal
yml > DB > defaults chain like every other RepositorySettings field (see
src/settings/repository-settings.ts / resolveEffectiveSettings).

Default rationale: hold_for_review ships as the default (not "preserve current behavior")
because the current unconditional-close behavior was never a deliberate, announced decision — it
was undocumented drift from commit 311b7613d (#1781). The 5 stale comments already describe what
the correct default should restore. Existing deployments (including JSONbored's own 3 repos) get
the safer behavior by default and can opt into one_shot per-repo if they want the old aggressive
behavior back.

Implementation notes

• The actual floor comparison lives in isConfiguredGateBlocker
  (src/rules/advisory.ts:882-886) — currently voids policy.aiReviewCloseConfidence entirely.
  This is where the new disposition branches in.
• Update all 6 locations the original audit found (the 5 stale comments +
  isConfiguredGateBlocker itself) to describe the new, now-accurate behavior — don't leave a
  7th stale copy behind.
• Wire the new field through the full template this codebase already uses for a new
  RepositorySettings field: migration (new DB column) → resolver
  (resolveEffectiveSettings/resolveRepositorySettings) → OpenAPI schema
  (npm run ui:openapi) → .gittensory.yml.example documentation, same PR, per this repo's own
  established pattern for adding gate-setting fields.
• Regression tests: (1) sub-floor consensus defect with hold_for_review → blocks but does not
  one-shot-close, ends up in the existing hold state; (2) sub-floor with one_shot → closes exactly
  like today; (3) sub-floor with advisory_only → non-blocking; (4) at-or-above-floor confidence →
  behavior identical across all three disposition values (the floor only matters below threshold).