review_now.py --force doesn't actually lift rev:off — reviewer self-skips anyway, still spends the run nf-efo1 ← Beads

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

What happened

On PR #909 (carries rev:off — pairing worktree, see #907), ran:

``` ./tools/pr/review_now.py 909 --force ```

Per notes/reviewer.md and review_now.py's own dispatcher output, --force is documented to lift rev:off for that one run and force a real re-review:

> --force re-reviews a PR whose verdict looks current and lifts rev:off for that one run.

The dispatcher-level mute WAS lifted — the run didn't short-circuit before starting (no "reviewer muted for this PR" outcome), and it spun up a full synchronous xhigh reviewer session (~44s, $0.41, total_cost_usd: 0.411606, log at /root/.ninefold-reviewer/logs/pr-909.20260814-061838.log).

But the reviewer session itself — reading the PR and its linked context (the PR body links #907, which documents the pairing/rev:off arrangement) — made its own independent call to skip anyway:

> "No prior verdict exists on this PR either, confirming it has never entered the review flow. Skipping per the rev:off mute — no review, no label changes."

Net effect: no verdict posted, no PR comment, no labels touched (./tools/pr/thread.sh 909 shows empty reviews/comments) — but the full cost of a real review run was still spent to reach that conclusion.

Why this is a bug

--force's entire documented purpose is to be "the way past" rev:off for one run (per review_now.py's own docstring/outcome text at the "reviewer muted for this PR" branch: ` --force overrides it for this one run ). If the underlying reviewer agent can still independently decide to honor rev:off after the dispatcher already lifted it, --force` doesn't actually do what it says — and worse, it burns a full xhigh run's worth of time/tokens to arrive at the same no-op the mute would have given for free via the fast-path.

Either: - the reviewer's own instructions/prompt need to stop treating rev:off as a signal to self-skip once it's been invoked via --force (the dispatcher already made that call), or - review_now.py's --force path needs to short-circuit on the same "no verdict, no cost" outcome the un-forced mute gives, rather than spending a real run to reach it.

Repro

1. Have a PR with rev:off applied.
2. ./tools/pr/review_now.py <n> --force
3. Observe: full-cost run, but result is still "skipped per rev:off mute", no verdict posted.

Found incidentally during a pairing session on #907 — filed unclaimed, not investigating further myself.