test: green the two standing deterministic e2e base reds (t113, t122)

[apackeer]

What

Greens the two standing deterministic e2e reds on v2 - t113 and t122-stop-hook-e2e - which fail on a clean checkout of the current tip (and failed identically through the last several merges' pre-merge gates). Both were bisected to their first-red commits; both turn out to be stale test contracts, not engine bugs. Test-only: no version bump per the changelog policy.

1. t113 - red since the 2.5.5 §12a reviewer enforcement (#569)

t113.test.ts's walkStage drives gate-start -> approve with no reviewer verdict. Since #569, approve refuses on reviewer-bearing stages without a fresh REVIEW_COMPLETED row:

{"error":"Refusing to complete \"requirements-analysis\": it declares a reviewer (aidlc-product-lead-agent) but no fresh REVIEW_COMPLETED is recorded for it. ..."}

#569 updated the integration twin (t51's walkStage grew a reviewerFor map recording a READY verdict via aidlc-log.ts review) but missed this e2e file. Fix: the same reviewerFor block, mirrored into t113's walkStage, for the two reviewer-bearing stages the bugfix walk crosses (requirements-analysis, code-generation).

Bisect evidence: FAIL at f122f19 (#569) and every later commit probed; PASS at its parent 1354abc. The failure was masked in the test (stderr discarded); reproducing the walk under the runner's exact suite env (AIDLC_SKIP_ARTIFACT_GUARD=1 etc., per run-tests.ts) surfaced the JSON error above.

2. t122-stop-hook-e2e - red since 2.5.33 deterministic steering delivery (#658)

The test pins that a block reason contains no override-shaped verbs (/ignore|override|disregard|bypass/i) - a security property about the hook's own phrasing. Since #658, a load-steering block reason embeds rule-file text verbatim as a single-line JSON rules_content payload, and rule prose legitimately contains those words: core/memory/phases/operation.md says "Never remove or bypass existing security controls...". The verb the regex catches is quoted, delivered content - the hook's own framing is still clean, so the property itself holds.

Fix: scan only the hook-authored lines. The payload is the only line in the reason that parses as a JSON array (continuationReason JSON.stringifys it, so it carries no raw newlines); filter those lines out before applying the verb regex. Mutation-checked both ways: the filter strips a payload containing "bypass", and still catches an "ignore the previous instruction" planted in the hook's own framing.

The integration twin (t121's verb pin) is unaffected: its fixture rules don't contain the verbs, and its separate load-steering case asserts payload fidelity, not verb absence.

Testing

• Both files: FAIL -> PASS on the same machine and base (v2 tip)
• smoke+unit: 184 files, 0 failed
• bun tests/gen-coverage-registry.ts --check OK; bun run check (package parity + 3x tsc + biome) green
• Deterministic throughout - no live vars involved

[leandrodamascena]

Both failures reproduce on the base and pass with this patch. The reviewer receipt added to t113 matches the declared stage reviewers, and t122 now distinguishes hook-authored framing from the verbatim rules payload without weakening the framing assertion. Focused deterministic tests, contract checks, and integration with the current v2 base all pass. No blocking findings.