test(runner): integration tests for repair invariants

[myselfsiddharth]

Closes #65.

Summary

tests/integration/repair-invariants.test.ts drives ReplayRunner end to end against a real headless Chromium page and fully scripted RepairModelClient fakes — no network, no API key, deterministic. tests/unit/runner.test.ts only ever exercised StubRepairModelClient (always corrected_action: null), which structurally cannot test what happens when a proposal is hostile or when the budget must be exhausted across several real, failing proposals.

All seven required cases, 9 tests:

1. Assertion tamper rejected — both paths, as separate tests: a client that reassigns ctx.assertion to a new object, and a client that mutates the live (non-frozen) step.assertion in place.
2. Strength downgrade rejected — the specific strong→weak attack, as its own test.
3. Budget honoured — a client that always proposes a real (but still-failing) action hits exactly maxRepairsPerRun attempts, ends REPAIR_EXHAUSTED, repair_count === 2.
4. Budget is per run, not per step — a two-step program where step 0 consumes both repair slots (succeeding on its 2nd attempt); step 1 gets REPAIR_EXHAUSTED having made zero calls to the client, and repair_count never exceeds the cap.
5. success_with_le_2_repairs accuracy — true for a run needing exactly 2 repairs and succeeding; false for a run needing 3 (with the cap explicitly raised to 3) even though it still succeeds — pins that this field is hard-coded to a threshold of 2, independent of whatever maxRepairsPerRun was configured to.
6. Cost accounted on failure — a client that burns tokens and then proposes null still shows those tokens in cost_repair.
7. A thrown client error does not silently pass the step — see the runner fix below.

Runner hole found and fixed here

Case 7 exposed a real gap: ReplayRunner catches a failing browser action and a failing assertion evaluation into typed StepOutcomes (src/runner/actions.ts, src/runner/assertions.ts), but had no equivalent catch around this.repairClient.propose(ctx) — the one other external call in the loop. A repair client that threw (a model API erroring, timing out, whatever) propagated straight out of run(), rejecting the whole run instead of failing one step. Fixed in src/runner/replay.ts: the propose() call is now wrapped in try/catch, and a throw is recorded as REPAIR_EXHAUSTED with the error message preserved — the same shape already used for a null proposal.

Guard verification (required by the issue)

Confirmed each assertAssertionUnchanged call is load-bearing, not vacuous, by disabling it and watching the corresponding attack succeed, then restoring it:

• Disabled only the ctx.assertion check (line 197). Result: the "reassigns ctx.assertion" test failed — the run silently returned task_success: true / REPAIRED_PASS instead of throwing. The other two tamper tests still passed, confirming they're caught by a different, still-active check.
• Disabled both step.assertion checks together (the one immediately after propose() and the one after the retry — line 196 and line 241; either alone still gets caught by the other, since a mutation made during propose() persists through the retry). Result: both the "mutate step.assertion" test and the "strength downgrade" test failed — the run reported REPAIRED_PASS with "assertion_strength": "weak" sitting right there in the result, completely undetected.
• Restored all three checks; full suite green again (verified below).

This is more precise than "comment out one line" because two of the three checks have partial redundancy for some attack shapes (a mutation made during propose() is still caught by the later check even with the earlier one disabled) — so I disabled combinations until each attack actually got through, to avoid claiming a check is load-bearing when it's actually just redundant with a neighbor.

Test plan

• All 7 cases implemented and passing (9 tests, tests/integration/repair-invariants.test.ts)
• Each guard verified to fail when its protection is removed (described above); guards restored before committing
• No network, no API key — all clients are local classes; only a local headless Chromium page is involved
• Runner hole found (case 7) fixed in this PR with the test that caught it
• npm run ci green, npm run test:canary green
• docs/gate/runner.md invariants section updated to reference these tests by path (invariants 1, 3, and a new invariant 6 for the throw-containment fix)

Checklist (from the issue)

• All seven cases implemented and passing
• Each guard verified to fail when its protection is removed; described in the PR body
• No network, no API key, no flakiness
• Any runner hole found is fixed in this PR with the test that caught it
• npm run ci, npm run test:canary green
• docs/gate/runner.md invariants section references these tests by path
• Branch track1/b4-repair-invariant-tests

🤖 Generated with Claude Code

[myselfsiddharth]

@copilot Review this PR after reading the docs.

[Copilot]

@copilot Review this PR after reading the docs.

Reviewed after reading docs/gate/runner.md and the PR changes. No additional code changes are needed from this comment; invariants coverage and runner behavior look consistent with the documented requirements.