load_recipe re-serve corrupts routing in live kitchen: clone.on_success rewired to register_clone_failure on 2nd+ serving (0.10.853)

[Trecek]

Problem

Within a live kitchen session on 0.10.853, load_recipe re-serves of the remediation recipe carry corrupted routing: clone.on_success is rewired from claim_and_resolve to register_clone_failure. The first serving (via open_kitchen) is correct; the second and third servings (via load_recipe) are corrupted. An orchestrator that re-loads the recipe then dutifully routes a successful clone to the failure path and the dispatch dies.

Evidence (dispatch e6a45f7f, session d8d50e44, 2026-07-07 ~20:52)

• Extraction of every recipe serving in the orchestrator session log (~/.claude/projects/-home-talon-projects-generic-automation-mcp/d8d50e44-4da4-4de3-8cc0-6aeb2be5bae5.jsonl), matching clone: tool: bootstrap_clone … on_success: <target>: ['claim_and_resolve', 'register_clone_failure', 'register_clone_failure'] — first serve correct, both re-serves corrupted.
• The orchestrator behaved correctly per anti-fabrication discipline: "The routing authority is the recipe YAML as loaded… I must follow it." — clone succeeded (work_dir, base_sha cefeaff57, 3052ms), then it followed the served register_clone_failure. Not a hallucination.
• On-disk recipes are correct (remediation.yaml:175 and the project copy both on_success: claim_and_resolve).
• Offline reproduction attempt: load_recipe twice AND _build_active_recipe twice with the exact dispatch ingredients (issue_url, source_dir, post_run_diagnostics=true) — does NOT reproduce (both composes correct, original object unmutated). The corruption therefore lives in the server-side serve/recall path that only exists in a live kitchen session — prime suspect: the pre-reveal/deferred-recall cache ([FIX] Double open_kitchen Context Cost — Pre-Reveal / Deferred-Recall Architectural Immunity #4092) being mutated in place by a post-serve pass (pruning, capability overrides, or the new check_review_posted wiring pass from Rectify: check_review_posted Step Wiring #4205 — this was the first remediation dispatch on 0.10.853).
• Same session's kitchen_status also warned: package_version: 0.10.853, plugin_json_version: None, versions_match: False — possibly unrelated, noted for completeness.
• Related lineage: Silent recipe content wipe on codex: unrepairable dangling route after pruning #3992 (dangling route after pruning), Double open_kitchen context cost: recall re-sends full recipe; Codex amplifiers #4089/[FIX] Double open_kitchen Context Cost — Pre-Reveal / Deferred-Recall Architectural Immunity #4092 (double open_kitchen recall).

Impact

Any pipeline whose orchestrator calls load_recipe after open_kitchen (a legitimate, common pattern) can fail immediately after clone — blocks the remediation queue and any recipe run on 0.10.853. Non-deterministic at fleet level because not all orchestrators re-load.

Expected behavior

Every serving of a recipe within a session is identical and correct: recall must serve an immutable snapshot; any post-serve mutation must operate on a copy. A serve-idempotence test (serve N times in one session, diff routing) should gate this permanently.

Prior Remediation Attempt (round 1) + descoping decision

Round 1 (dispatch d01edea9, 3h25m): Part A is complete on pushed branch impl-4208-20260707-230557 — session_serve_overrides snapshot closing the serve-context asymmetry (1cc88f305), arch-guard fixes (e31bdd5a3), and 5 serve-idempotence tests (529016f1f, on the branch history). Part B (skip-guard-requires-on-success rule) repeatedly context-exhausted with ~93 recipe-layer failures and is descoped to #4209.

Guidance for round 2 — SHIP PART A ONLY: fetch branch impl-4208-20260707-230557; take the Part A commits (529016f1f, 1cc88f305, e31bdd5a3) and NONE of the Part B commits (40aeaade9, f178603c0 — those belong to #4209); verify the serve-idempotence tests pass and the full suite is green at that scope; then PR/review/merge closing this issue. Do not implement any new rules.

Round 2 tail status + remaining defect (for round 3)

PR #4210 exists and carries: Part A (serve-overrides snapshot + serve-idempotence tests), 7 review-resolution fixes (review approved, id 4654241982), and an attempted test-isolation fix (6eb5cd0ff: reset_session_serve_overrides helper + fixture wiring) that proved INSUFFICIENT.

Remaining defect blocking merge: tests/server/test_tools_agents.py::test_unlock_agent_pack_session_scoped fails order-dependently in CI ("assert not True") — 3 occurrences (merge-group run 28944804388, branch runs 28938034846/28952937562); passes in isolation and in some full runs. Diagnosis so far: when _state._ctx is left non-None by an earlier test on the same xdist worker (with ctx.backend wired / kitchen gate state), the victim's bare Client(mcp) lifespan boot re-enables tags via the pre-reveal path — clearing only session_serve_overrides/session_serve_defer_unresolved (the 6eb5cd0 fix) does not prevent this. The real leak is broader lifecycle state (_state._ctx and/or gate/kitchen-open state) surviving between tests.

Round 3 scope: adopt PR #4210's branch (do NOT open a new PR — push to it); root-cause the ordering leak properly (find the polluter class; decide whether the fixture must fully reset _state._ctx/gate state, or the victim test needs hermetic setup, or the boot pre-reveal path needs a guard); make the test deterministically safe under xdist; prove with repeated targeted orderings via PYTEST_TEST_PATHS=... task test-check plus full task test-check; then the PR merges via the queue (review already approved).