the terminal that never closes: every launcher waited for ANY btl4.exe on the machine

Operator report: "X-closing the game leaves the terminal open and leaves
orphaned processes."  Investigated on the rig against 4.11.600.

The terminal half is real and is THIS: :btwait polled
`tasklist /FI "IMAGENAME eq btl4.exe"`, which is machine-wide, so a bat that
launched nothing at all keeps spinning while an unrelated instance lives --
proved with btwait_probe.ps1.  A second client, the operator's own pod, or an
orphan from a crash therefore hangs every join window, which reads as "the game
never exited" and invites people to start killing processes.  All four
launchers carried the identical block.

Fix: snapshot the btl4 PIDs alive BEFORE the launch; wait only on PIDs absent
from that snapshot.  The `if /I "%%P"=="btl4.exe"` guard is deliberately kept --
tokens=2 alone parses tasklist's "INFO: No tasks are running" line as a PID and
spins forever with nothing running, which would be worse than the bug.

Verified with the text lifted verbatim from the shipped play_solo.bat: nothing
running -> signs off (the regression guard); someone else's instance -> signs
off; our own generation -> keeps waiting; decoy gone -> signs off.  The patched
bat still launches (pid + launch_report.txt).  NOT verified: the full handoff
E2E, because the bat blocks on the FE menu waiting for a human.

The orphan half did NOT reproduce on 600: closing the MAIN window exits cleanly
in ~1s during solo model-load, in the relay join wait, and after a real console
launch, with the relay logging the seat freed.  The orphans the playtesters saw
match 584 and earlier, where every close relaunched.  Full write-up, including
the aux windows that hide instead of closing and the WM_QUIT that BTLoadPump
swallows, in phases/phase-12-orphan-processes.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

context/build-and-run.md

@@ -49,6 +49,16 @@ run\run.cmd [EGG]      # default DEV.EGG; cd's to content\ and runs btl4.exe -eg
   mission generation the menu launched (the child inherits the parent's cwd). Invisible for years
   because every launcher `cd`s to `content\` first; it became reachable once glass became the
   desktop default and a zero-arg launch started opening the menu.
+- **The launcher's handoff wait must track ITS OWN generation [T2, 2026-07-27].** The front end
+  does not stay resident — it `CreateProcess`es the mission generation and exits — so every
+  launcher ends in a `:btwait` loop that waits for the handed-off process before printing its
+  sign-off. That loop used to poll `tasklist /FI "IMAGENAME eq btl4.exe"`, which is **machine-wide**:
+  a second client, the operator's own pod, or an orphan from a crash kept the window spinning
+  forever, which is the field report *"closing the game leaves the terminal open"*. Fixed by
+  snapshotting the PIDs alive before the launch and waiting only on PIDs absent from that snapshot.
+  ⚠ **Keep the `if /I "%%P"=="btl4.exe"` guard** — parsing tasklist with `tokens=2` alone reads its
+  *"INFO: No tasks are running"* line as a PID and spins forever with nothing running. Full
+  investigation, including which windows exit vs merely hide: `phases/phase-12-orphan-processes.md`.
 - **Why this is a BT411-only hazard [T1].** The 1995 pod shipped ONE folder — `BTL4OPT.EXE` sits
   next to `BTL4.RES`/`VIDEO\`/`GAUGE\`/`AUDIO\` (it is still there in `content\`) — and RP411/RP412
   keep that shape (`pack-dist.ps1` copies the exe and every asset dir into one dist root). BT411's