fix(review): bot-capture satisfaction doesn't clear the screenshot-evidence-completeness blocker

[JSONbored]

Context

While validating #4564 (the `review.visual.production_url` fix) against a real metagraphed test PR (JSONbored/metagraphed#4713, closed without merging), found a separate, confirmed-live bug in the #4535/#4540 screenshot-evidence-completeness matrix mode.

What happened

1. feat(ui): config-generator AI provider mode field group (#2208) #4713 touched `apps/ui/src/components/metagraphed/app-shell.tsx` (a visual change, in `screenshotTableGate.whenPaths` scope).
2. Bot-capture ran successfully and produced a real desktop before/after pair (two distinct R2-hosted PNGs, confirmed via direct URL inspection — not placeholders).
3. `markPullRequestVisualCaptureSatisfied` correctly persisted `visual_capture_satisfied_sha = head_sha` — confirmed via direct `psql` query against the self-host Postgres instance on edge-nl-01:
   ```
   number | head_sha | visual_capture_satisfied_sha
   4713 | 3498783e04c7224a6634c242bdc29380d98c05b4 | 3498783e04c7224a6634c242bdc29380d98c05b4
   ```
4. Despite that, the panel comment's screenshot-evidence-completeness blocker fired anyway: "no before/after screenshot table (3 viewports × 2 themes) was provided, which screenshot-evidence-completeness treats as a blocker regardless of how trivial the visual diff looks."
5. Triggered an explicit re-run via the panel's `gittensory-rerun-review` checkbox (after the DB write above already existed) — the blocker fired again, identically.

Expected behavior

Per `src/review/screenshot-table-gate.ts`'s own doc comment: "`botCaptureSatisfied` ⇒ no violation regardless of mode (an automated capture is equivalent to a hand-authored table...)" — line 333: `if (input.botCaptureSatisfied === true) return NO_VIOLATION;`. This should have short-circuited the matrix-mode check entirely on the re-run, once `visual_capture_satisfied_sha` matched `head_sha` in the DB.

Suspected root cause (unconfirmed — needs investigation, not yet fixed)

`src/queue/processors.ts:2946` computes `botCaptureSatisfied` from an in-memory `pr` object (`pr.visualCaptureSatisfiedSha === pr.headSha`). The capture-and-mark step (`markPullRequestVisualCaptureSatisfied`, ~line 10834) writes to the DB but may not update that SAME in-memory `pr` object within the pass, and/or the "re-run" trigger path may not re-fetch `pr` fresh from the DB before evaluating the gate — meaning the intended bypass never actually reaches a call site with the correct value, on either the original pass or a re-run.

Impact

For any repo with matrix mode enabled (currently only metagraphed), bot-capture provides zero benefit toward satisfying the screenshot-evidence-completeness gate — contributors get blocked regardless of a successful automated capture, undermining the entire point of #3607's automated-capture epic (auto-evidence "so contributors touching apps/ui/** don't have to submit their own screenshots" — they currently still do, or get closed).

Suggested next step

Trace the exact `pr` object lifecycle between the capture step and the gate-evaluation call site across both the original webhook pass and the re-run trigger path; confirm whether either ever re-reads `visual_capture_satisfied_sha` fresh from the DB before evaluating `evaluateScreenshotTableGate`.

[linear-code]

JSO-3377

[JSONbored]

Root cause was different than originally hypothesized — corrected and fixed

Traced this properly using the self-host audit trail rather than guessing further from static code.

The original hypothesis (stale in-memory `pr` object in the deterministic gate) was wrong. Direct evidence from `audit_events` on edge-nl-01 for PR #4713:

• Only ONE `agent.action.hold` event exists (from the very first review pass), and its detail is `close withheld for protected author on gate blocker missing_linked_issue` — not a screenshot-related reason.
• The panel-retrigger path (`maybeProcessPrPanelRetrigger`) calls `maybePublishPrPublicSurface` but never calls `maybeRunAgentMaintenance`/`runAgentMaintenancePlanAndExecute` — the function that actually computes `evaluateScreenshotTableGate`. So the deterministic gate never even re-evaluated on the re-run I triggered, and on the original pass it correctly saw `botCaptureSatisfied` and never fired a screenshot-related close.

Real root cause: the AI reviewer's own free-text commentary was independently (and wrongly) flagging "no before/after screenshot table" as a blocker, worded almost verbatim from the private `screenshot-evidence-completeness.md` review-skill instructions I'd written earlier. This is structurally guaranteed to be wrong in cases where bot-capture later succeeds: `runAiReviewForAdvisory` (the AI review call) runs at `src/queue/processors.ts` ~line 9973, while `buildCapture`/`hasSuccessfulBotCapture` runs later in the same pass at ~line 10798+ — the AI has no way to know capture will succeed, because it hasn't happened yet when the AI's context is built.

Fix: appended guidance to the private skill file (`review/skills/screenshot-evidence-completeness.md` on edge-nl-01, config-only, no code/PR/redeploy needed) instructing the AI reviewer to never independently flag missing screenshot evidence as a blocker — the deterministic gate is authoritative for that dimension and already accounts for capture succeeding later in the pass. At most, a neutral non-blocking note.

Verified live: reopened the exact same commit from #4713 as a fresh PR (metagraphed#4717, same head SHA, so the R2 capture cache was reused — no new renders needed) to isolate the AI-review-only effect.

• Before the fix: screenshot evidence was 1 of 2 hard blockers.
• After the fix, same commit: the blockers list shrank to just the (correct) missing-linked-issue one; the screenshot mention moved to Nits with exactly the neutral wording specified: "No manual before/after screenshot table was submitted for this visual footer change; the repo's automated capture pipeline will supply evidence if eligible, so this is not itself blocking."

Both test PRs (#4713, #4717) closed without merging — validation-only, no linked issue.

Closing this issue as fixed.