fix: two review defects — dead-end detector silent on alternating calls, recovery metric counted deflection

[Lexus2016]

Two defects found in post-merge review of work merged earlier today. Both are in code I wrote or repaired, both are confirmed by reproduction, and both would have degraded the signal the evolution loop runs on.

Independently flagged by a cross-provider review (Gemini via consilium) and then reproduced locally before fixing.

---

1. Dead-end detector went silent on alternating calls — agent/loop_guard.py

Repairing #1349 I added a liveness requirement: the repeated signature must be re-issued by the latest tool turn. That part is right — 5x terminal then a read_file, or 8x terminal then a text reply, count as progress everywhere else in that module (TestRunBoundaries).

What was wrong is the order of operations. The code ranked the window with most_common(1) and then required that winner to be live. When the agent alternates between two stuck calls, those two conditions select different signatures:

pytest, ruff, pytest, ruff, pytest, ruff, pytest, ruff   (each x4)
  most_common(1) -> "pytest"   (insertion order breaks the tie)
  live signature -> "ruff check"
  -> no match -> SILENT

Both calls are four-deep in identical re-issues. That is exactly the dead end #1312 exists to catch, and it went unreported.

Fix: look up the live signature first, gate on its own count. Liveness requirement unchanged.

New TestAlternatingCallsAreStillDeadEnds covers: fires at threshold, quiet below it, and names the live call rather than the most-common one.

---

2. Refusal-recovery counted deflection and explanation — scripts/introspection_extract.py

The pivot clause in _RECOVERY_RE allowed second person. So handing the work back to the human counted as a recovery:

Text	Was counted	Actually
"I can't access that URL, however you can try visiting it yourself."	recovered	deflection
"I cannot do that. Instead, please contact support."	recovered	deflection
"I don't have permission. But you will need to run it manually."	recovered	deflection
"I can't do that, but I can tell you why it failed."	recovered	explanation, not an alternative path

This inverts the metric: it improves whenever the agent gets more polite about giving up — the precise behaviour #1327 exists to eliminate.

Fix: pivot clause is first-person only, plus a _NON_RECOVERY_RE veto for deflection (contact support, you can, yourself, manually) and explanation-instead-of-action (I can tell you why). Vetoing beats narrowing the recovery pattern — these shapes are open-ended, and under-counting a real recovery is far cheaper than a rate that rises when the agent gives up nicely. Also adds first-person phrasings the original missed (let me try, I'll write).

Measured impact on the real corpus

Same 4629 sessions, same 143 refusals:

before:  51 recovered   rate 0.3566
after:   31 recovered   rate 0.2168

20 of the 51 were false positives — the headline number was inflated by ~64%. The 21.7% figure is the one Child C (#1327 recovery dispatcher) should be measured against.

---

107 passing across the four loop-guard suites; 50 in test_introspection_extract.py (7 new). Ruff clean on all four files.

Refs #1312, #1366.

[Lexus2016]

Third and fourth defects found while fact-checking my own docs from #1362 against the code they describe. Both now in this PR (commit 21b98af99).

3. A threshold that does not exist. The introspection SKILL.md claimed classify_verdict_by_rate() implements "a rate rise >20% is regressed, a drop >5% is confirmed, anything between is stable". Reading the function:

rel_delta = (current_rate - baseline_rate) / baseline_rate
return "regressed" if rel_delta > regression_threshold else "confirmed"

There is no 5% branch and no stable verdict. Three ledger values exist, not four. A skill file is executable guidance — an agent looking for a stable band that isn't there records the wrong verdict, and a wrong regressed re-opens issues that were actually fixed.

4. Two smaller inaccuracies in the same block:

• failure_rate was described as "failures ÷ sessions_scanned", implying a scalar. It is a dict keyed by tool, like tool_failures.
• The reason bucket is emitted as quota/billing; the doc listed quota, so an exact-match lookup finds nothing.

Verified good: the record-merge example. Rather than counting positionals by eye I ran the documented command and read the ledger line back — 0.42 lands in baseline_failure_rate. Unchanged.

Running total for this verification round: 4 defects, all in code or docs I merged today, all reproduced before fixing.