vms-562: mmk_drive — key completion on the DCL-computed marker, not MMK self-exit timing

[baron-3dl]

Problem

tests/qemu/test_syssvc_mmk_drive (self-host spine #4) asserted MMK.EXE reaped within a tight grace:

MMK.EXE completed (it detected the MMK____status= end-of-command marker and exited, rather than deadlocking in $HIBER)

Under contended TCG (the Kernel Executive job runs ~76 suites in ONE QEMU VM near a 120s wall), MMK echoes the DCL-computed marker OVMXB23:42 and drives the build correctly, but its teardown-and-exit lags the marker — so the reap assertion reddens and the whole Kernel Executive (vms.ko via /dev/vms, QEMU) gate goes red on unrelated PRs (bit #499, #492).

Fix — key success on the marker, but wait for MMK's clean rundown

Like spine #6 (test_syssvc_mmk_build, vms-d1b), success is keyed on the proof captured — the DCL-computed marker OVMXB23:42 echoed back over the mailbox drive (the independent oracle) — not on MMK's self-exit timing. DRIVE_TIMEOUT_MS unchanged (25s); no timeout bump.

Teardown hygiene against the REAL shared executive (Rule 9): the parent still waits (bounded, unasserted) for MMK to exit on its own. MMK $CREMBXed its command + result mailboxes, armed a write-attention AST, and lib$spawned a persistent DCL subprocess, and tears all of that down in close_subprocess()/sp_close() ($FORCEX + $DELPRC the DCL, $DASSGN both mailboxes) as its last act before exiting. SIGKILLing MMK the instant the marker appears skipped that teardown — orphaning the DCL grandchild (which held this suite's stdout FIFO open and sat blocked on the leaked mailbox) and leaking the mailboxes/AST into the executive the next suite shares — deterministically wedging test_syssvc_procnam and stalling the run at ~60/76 at any wall. Now the parent polls for the marker while draining MMK's output until MMK exits on its own, letting sp_close() reclaim everything; SIGKILL is a last resort reached only by a genuine wedge, which occurs only under the isolated one-defect-per-boot negctl.

Discriminating power preserved

A genuine mid-drive \$HIBER deadlock echoes no marker → got_marker stays 0 → the bound elapses → fails hard. Negctl facility_defects.sh mmk-drive-command-not-sent (zero command bytes → wedged DCL → no marker) still reddens via the untouched require_fail assertion; its knock_on_fail (the removed reap assertion) is cleared so the observed red set equals require_fail + knock_on_fail exactly (manifest selftest passes). No-executive honest-skip branch unchanged (Rule 9 / INV-6).

Proof

Built tests/qemu/Dockerfile from a clean git archive HEAD (414632aa) and ran the FULL Kernel Executive suite under pure TCG:

=== FINAL RESULTS: 76 suites passed, 0 suites failed ===

76/76 — the run reaches test_syssvc_procnam and everything after mmk_drive (the old teardown-leak stall at ~60/76 is gone), with 0 failed assertions. CI green-by-SHA on this commit for Build & Test + Kernel Executive.

🤖 Generated with Claude Code