reviewer-proposed diffs as acceptable-verbatim suggestions, exempt from the freshness gate nf-m6n ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/920 by tools/beads/import_github.py's reconcile pass.

Motivation

Observed on #891/#898: the reviewer's round-6 verdict included a fully-specified, prose-exact fix for a non-gating finding —

> **F1 — ./dev.py --help still prints the claim this commit deleted from every > other surface. ... The wording already chosen three times over is the > fix: every process a verb runs is echoed.**

filed unclaimed as #898 since the PR was already approved. A later session (dev-py-oracle) picked up that exact wording, made the 2-line edit, then reverted it and merged at the clean approved sha instead — because landing it would move the head sha and trigger merge_pr.py's freshness gate (#586): *"a green label must never certify a head the reviewer hasn't seen"*, meaning even a trivial, reviewer-authored fix costs a full review_now.py pass (~12 min, ~$5) to land.

That's the gate working as designed, not a bug — but it creates a real disincentive against folding in cheap, obviously-correct, reviewer-suggested fixes, pushing them to accumulate as separate filed issues instead.

The idea

Let the reviewer propose an actual patch/diff (not just prose) for findings where it can specify the fix exactly. If a dev applies that patch verbatim, landing it doesn't need to re-trigger a full re-review — the reviewer has, in a real sense, already "seen" that resulting content, because it authored it.

This is a sibling of the existing pure-rebase restamp path (dispatcher's delta check: unchanged content restamps the verdict instead of demanding a fresh review). Same shape, widened condition: restamp when the delta is either empty **or exactly matches a hash-pinned patch the reviewer proposed in its own verdict**.

Design considerations flagged in discussion

1. Byte-exact and isolated. The applied diff must match the proposed patch hunk-for-hunk, in a commit containing nothing else. Bundled with even one unrelated line, the whole push should fall back to a normal re-review — otherwise this is a laundering path for unreviewed content riding along with a legitimate suggestion. 2. Needs a structured reviewer output. Today findings are prose (*"the wording already chosen three times over is the fix"*), not a parseable patch. Real work in tools/reviewer/, not just merge_pr.py. 3. Scope to advisory/non-gating findings first — the exact F1 case above. Highest value, lowest risk, and the actual friction observed. Gating GAPS items still want a real re-review since convergence is more than "did you apply my patch." 4. Stale-base handling. If head has moved since the verdict, the patch may not apply cleanly — fail closed into a normal review rather than fuzzy-apply.

This touches the freshness/authority invariant (#586/#702/#785 territory) — authority.py and its test suite are heavily invested here, so this wants a /design round to scope and harden before it touches the merge gate, not a quick patch.

Unclaimed, unlabelled.