PR 2 rescue retention: finish gate validation after impl-placement correction

[ryanbreen]

PR 2 rescue retention is on branch sched/3f-pr2-rescue-retention.

The strict-3 invocation at 34b36142f4be8d4d3af07e105e258a73e6ca7ac2
stopped in structure preflight: 63/64 suites passed. In
tests/coreproof_sites_structure.rs::every_scheduler_seam_is_classified_correctly,
the scanner's first-impl assumption rejected the additional early
impl Scheduler containing the retention helper.

The helper now lives in the existing impl; the unchanged coreproof suite
passes 4/4 tests, and the rescue mutation matrix passes its expected legs.
The corrected aarch64 boot_tests build exits 0. This has not been validated
by another boot-gate attempt: the round's PROOF ONCE and R52 instructions
require authorization to resume after the first unmatched gate red.

Remaining validation: a corrected strict-3 run, beast x86 build profiles and
one x86 boot-tests gate, then the aarch64 production gate LAST. The beast
production build was deliberately interrupted before any x86 gate after the
R52 stop. No x86 gate or production gate result is claimed.

Evidence and the environment-specific soft-float toolchain repair are in
docs/planning/green-program/aarch64-testing/3F-PR2-2026-09-07.md and
docs/planning/green-program/aarch64-testing/serials/3f-pr2/ on this branch.

[ryanbreen]

Resumption was explicitly authorized by the human. The earlier R52 interpretation applied the separate closed arc to this round incorrectly; it does not block this legitimate post-fix continuation.

At bb5d311:

• Direct structure invocation: 103/103 tests, exit 0.
• Mac strict-3: 64/64 preflight suites and 3/3 boots, exit 0.
• Beast lane synced to that exact HEAD. First x86 attempt stopped at 62/64: context-restore timeout and QMP fixture dump-command assertion. Observed host load reached 30.79.
• Single authorized contention retry, with two workers and unchanged 300-second suite budget: 63/64; QMP passed 15/15, context-restore timed out again. Neither attempt reached the x86 build or boot. No further retry was performed; no disk-871 signature was observed.
• Mac production gate ran LAST: 64/64 preflight, clean build and 1/1 boot, exit 0.

No kernel or ratchet source changed; the prior corrected-source mutation matrix remains applicable. Evidence uses new continuation-* filenames in docs/planning/green-program/aarch64-testing/serials/3f-pr2/. The round document records the partial outcome and preserves the earlier failed attempt.

Issue 941 stays open for x86 validation under an adequate host execution window. PR 942 stays draft; completed gate acceptance is not claimed and no merge is performed.

[ryanbreen]

Recorded the completed fourth x86 boot in merged PR #951 (merge 9f79cb7), preserving the three earlier preflight failures.

The run at e42b4d0 ended with x86 frame-custody gate run 1: PASS, exit 0 and ended_by=scored_pass. Evidence and file:line quotations are in docs/planning/green-program/aarch64-testing/3F-PR2-2026-09-07.md, Landing-x86.

git rev-parse e42b4d04^{tree} 70aec756^{tree} returned:

0439e627f5d9f36a9c3d53cad3df4583ccdab893
867432c6b43c7a4c9a7d434a85bd087417957e77

The trees are UNEQUAL. The diff contains only documentation/evidence paths, recorded in serials/3f-pr2/landing-x86/tree-comparison.txt relative to that document.

Issue 941 remains open under the requested full-tree equality condition. Remaining: x86 boot evidence for the exact merged tree, or explicit acceptance of the documentation-only tree difference. Earlier comments narrow the outstanding validation to x86 build/boot; this comment does not reopen the earlier strict-3 and production results.

Docs validation: bash scripts/run-structure-tests.sh exited 0 (103 passed), recorded in docs/planning/green-program/aarch64-testing/serials/3f-pr2/landing-x86/docs-structure.txt.

Not claimed: a new boot in this session, execution at 70aec75, full-tree equality, merge-tree production validation, live fourth oracle leg, prompt home dispatch, live SGI delivery, or closure of issue 941.

[ryanbreen]

(reposted without host details)

A third x86 gate attempt was run after the continuation's two attempts, once
beast load had visibly dropped (host uptime 6.73, build environment 1.13). Load rose
again mid-run and context_restore_structure timed out a third time with the
identical signature (63/64 structure suites, no SCSI/I/O error, kernel build
and QEMU never reached).

Three independent attempts now show this exact signature on this exact
suite: default workers, the one CAP-authorized retry at
BREENIX_STRUCTURE_JOBS=2, and this third default-worker attempt. This is
consistent beast contention from the other lanes sharing the host, not a
defect in kernel/src/task/scheduler.rs (unchanged since be7b485c) or in
the x86 build.

Remaining work is unchanged from the prior comment: an x86 build/boot
attempt when host load has settled, tracked here. Evidence for all three
attempts is under docs/planning/green-program/aarch64-testing/serials/3f-pr2/
at commit 35d9bc4d1845bce7bdd0246e435fb65b0232a13a on
sched/3f-pr2-rescue-retention. Structure suites, strict-3 (3/3), and the
aarch64 production gate are all green at that commit.