fix(ce-code-review): fall back when a started peer never reviewed the diff (EveryInc#1842)

Author: tmchow

docs/guides/ce-code-review.md

@@ -124,7 +124,7 @@ That last point is what makes review strictness compound. Notice a mistake worth
 
 ## Cross-model adversarial pass
 
-When adversarial is selected and the working tree is the reviewed head (current branch, or a PR whose local tree already matches the PR head), the adversarial lens runs through one model provider different from the host, in a separate read-only process. A started peer replaces the in-process `adversarial` persona; they never both receive the same brief. The in-process persona runs if the peer cannot start, or if the started peer returns only session-quota or auth-context failure. In that case the next announced different-family peer is tried when one is eligible, otherwise the local persona covers the lens. An exact provider-overload 529 gets one same-route retry; repeated overload, another stubborn transient rate limit, or max-turn exhaustion falls back locally without an unbounded retry loop. Remote PR or branch diffs stay on the in-process persona, because that reviewer can inspect the fetched refs.
+When adversarial is selected and the working tree is the reviewed head (current branch, or a PR whose local tree already matches the PR head), the adversarial lens runs through one model provider different from the host, in a separate read-only process. A started peer replaces the in-process `adversarial` persona; they never both receive the same brief. The in-process persona runs if the peer cannot start, or if the started peer never reviewed the diff, for example because of a session quota, an auth-context failure, or a CLI that rejects an option its installed version lacks. In that case the next announced different-family peer is tried when one is eligible, otherwise the local persona covers the lens. An exact provider-overload 529 gets one same-route retry; repeated overload, another stubborn transient rate limit, or max-turn exhaustion falls back locally without an unbounded retry loop. Remote PR or branch diffs stay on the in-process persona, because that reviewer can inspect the fetched refs.
 
 Agreement between the peer and another in-process reviewer is a strong promotion signal in synthesis.
 

skills/ce-code-review/references/cross-model-recovery.md

@@ -8,14 +8,14 @@ Read this only from the branch that sends you here: Stage 3d's no-job-id start f
 - **Ran but produced no usable output** — the job reached `done` (or any terminal state) yet no `adversarial-<provider>.json` exists. The peer ran and received the content but returned nothing in the schema shape: unparseable output, or empty findings the script dropped. This is different from not-run: note "cross-model pass: peer ran, no usable output" in human-facing markdown Coverage. Never fail the review. When the diagnostic classification below proves this was a no-review outcome, run the did-not-run fallback before treating the lens as covered.
 - **Started but not `done`** — the final status read reports `failed`, `timeout`, or `died-without-result` (a job reaped at the shared deadline records `timeout`, with the reap noted in its reason) → still non-blocking, but never silent: name the peer and its terminal state in Coverage (e.g. "cross-model adversarial peer: timeout"). Saying nothing is correct only for passes that never started or were skipped. When the diagnostic classification below proves this was a no-review outcome, run the did-not-run fallback rather than leaving the lens uncovered.
 - **Classify the skip reason before deleting.** Read `out.log` before cleanup, including bounded lines prefixed `peer skip evidence:`. Judge the full diagnostic; do not grep for a closed phrase list. Attribute an account authentication failure only after provider-capable dispatch is positively established by the launch context or provider response; then report the observed failure and login or credential-refresh remediation. Without that proof, login-shaped peer text describes only the peer's execution context: a sandboxed host produces the same signal as a genuine logout, so never report it as the user's account being logged out or prompt a login command.
-  - Session or usage quota: the peer did not review. Do not retry that route; run the did-not-run fallback.
   - Any authentication-shaped failure: the peer did not review, whether the explanation is credential-attributable or execution-context-only. Attribution changes the explanation, not coverage; run the did-not-run fallback.
   - Transient provider-capacity or rate-limit failure: the worker exclusively owns the one same-route retry under Step 1's exact-overload condition (the worker alone retries, once, after an exact 529). Once a provider no-review outcome reaches the host, dispatch in-process `adversarial-reviewer`; the host never restarts that peer. Do not run the did-not-run fallback or switch recipients.
   - Max-turn exhaustion: dispatch in-process `adversarial-reviewer`. Do not retry the peer or switch recipients.
-  - Anything else: name the observed failure; do not run the did-not-run fallback.
+  - Any other diagnostic that shows the peer never reviewed the diff: it hit a session or usage quota, or its CLI failed before reviewing, for example by rejecting an option that its installed version does not support. Do not retry that route; run the did-not-run fallback.
+  - Anything else, including a diagnostic that cannot show whether the peer reviewed: name the observed failure; do not run the did-not-run fallback.
 - **Did-not-run fallback** (first no-review outcome, including the first one): the started job did not cover the adversarial lens. Do not retry that same route. Then:
   1. If this is the first replacement attempt, the failed recipient was **not** an explicit user-stated preference (Step 1 item 1), and another attested-different installed+allowlisted target remains: announce that new recipient and start a new job with a new `CROSS_MODEL_FIXED_ROUTE`. Wait for it with the remaining shared deadline and fold its artifact the same way as the first job. That job now covers the lens. Never switch recipients inside the worker. If this replacement also ends in a no-review outcome, do not start a third peer; take step 2.
-  2. Otherwise (explicit recipient, or no other eligible peer): dispatch in-process `adversarial-reviewer` now. Coverage records the peer as not-run for quota/auth and names the cover in exactly this form: `adversarial lens: in-process fallback (cross-model peer not run: <reason>)`, matching `peer.outcome: in-process-fallback`. Never write `harness-native fallback` here: that phrase is `ce-work`'s ship-gate signal for a review that ran without `ce-code-review` at all, and reusing it makes a complete review read as a skipped one.
+  2. Otherwise (explicit recipient, or no other eligible peer): dispatch in-process `adversarial-reviewer` now. Coverage records the peer as not run, with the observed reason, and names the cover in exactly this form: `adversarial lens: in-process fallback (cross-model peer not run: <reason>)`, matching `peer.outcome: in-process-fallback`. Never write `harness-native fallback` here: that phrase is `ce-work`'s ship-gate signal for a review that ran without `ce-code-review` at all, and reusing it makes a complete review read as a skipped one.
   A config or default selection is not an explicit user-stated preference. One replacement only; never silently continue to another recipient.
 
 ## Trust boundary (maintainers)