control board: stale registrations and a launch-test leak (#1504)

Two defects in 69f99323, reported by the professor session and verified.

The darkwing launch test's flock-contention spawn ran without the fixture
config, so launch.sh re-entered scripts/mosaic against the real data root
and wrote fixture records for darkwing, dewey and filbert there. That
spawn now names the fixture config, and both launch test files set
MOSAIC_CONFIG to a nonexistent path and clear MOSAIC_LAUNCH_REGISTERED
process-wide, so a spawn that forgets fails instead of polluting.

A registration is written before the launch script's own checks, so a
refused launch left a record with a dead pid that the board honoured. The
scanner now probes the recorded pid (pidAlive, signal 0); a gone pid makes
the record stale: still on the Registered line with alive false, derived
task, project and workspace win, index gains registrationStale, CLI
summary gains a stale count.

Fleet launchers marked not planned per Jason. Board 90/90, seat 15/15,
launch scripts 5/5. Sonnet review APPROVED.

Co-Authored-By: Claude Fable 5.1 <[email protected]>

docs/plans/2026-09-12_control-board-mvp.md

@@ -250,7 +250,10 @@ package `packages/seat` and wrapper `scripts/mosaic`:
   plain `agents/darkwing/launch.sh` registers too. rocko registers but is
   still not on the board: it has no pi session log to scan. Gap, not a bug.
 - Fleet launchers under `~/.mosaic` are not edited from this repository.
-  One-line change for orch-01 to apply in
+  Not planned (Jason's ruling, 2026-09-12, relayed by the professor
+  session): fleet seats stay on the old launchers; only `agents/` seats
+  use `scripts/mosaic`. The one-liner below is kept for the record only.
+  One-line change that would do it, in
   `~/.mosaic/fleet/bin/launch-seat.sh`, after `SEAT_DIR=` is set (the
   per-seat `launch.sh` files are shims and need nothing):
   `[[ -n "${MOSAIC_LAUNCH_REGISTERED:-}" || "$CHECK" -eq 1 ]] || exec /mnt/storage/src/mosaic-stack/scripts/mosaic launch --harness pi "$SEAT_DIR" -- "$@"`
@@ -290,3 +293,34 @@ package.json (0.85.1)". Commit 557aba0f (#1499) moved the pin without an
 already 0.85.1, which hid it). Fixed by `npm ci`; the refusal now names
 both versions. Jason questioned the pin itself; it is canon (AGENTS.md
 "Version pin") and stays unless he decides otherwise.
+
+**2026-09-12 — Two defects in 69f99323, reported by the professor session
+and verified here.** (1) The darkwing launch test's flock-contention spawn
+inherited the plain environment, so the launch script re-entered
+`scripts/mosaic` with the default config and wrote fixture records for
+darkwing, dewey and filbert into the real data root (dead pids, workspaces
+under `/tmp`), overwriting the record of Jason's live darkwing. Fix: that
+spawn names the fixture config, and both launch test files now set
+`MOSAIC_CONFIG` to a nonexistent path and clear `MOSAIC_LAUNCH_REGISTERED`
+for the whole process, so any spawn that forgets fails instead of
+polluting. The three fixture records were deleted by hand; Jason's next
+darkwing launch writes the real one. (2) A registration is written before
+the launch script's own checks, so a refused launch (Jason's Pi pin refusal)
+left a record with a dead pid that the board showed as registered. The
+scanner now probes the recorded pid on every pass (`pidAlive`, signal 0);
+a gone pid makes the record stale: still on the Registered line, marked
+stale with `registered.alive` false, but derived task, project and
+workspace win. Index gains `registrationStale`; the CLI summary a stale
+count. Tests: board 90/90 (was 89), seat 15/15, launch scripts 5/5; the
+launch tests run against the real data root untouched (checked by
+timestamp). Also from Jason: fleet seats stay on the old launchers; the
+orch-01 one-liner above is marked not planned.
+
+Observation from Jason, same day: after relaunching darkwing, the row's
+"Last message" was still from the earlier session. Cause, not a scanner
+bug: Pi writes the session log on the first message, and `--continue`
+resumes the newest existing log, so until the relaunched seat sends or
+receives a message there is nothing newer to read. The registration's
+`startedAt` and pid are the only trace of the relaunch, which is what the
+Registered line is for. A later refinement could say "relaunched at X, no
+messages since" when `startedAt` is newer than the last activity.

docs/plans/CURRENT.md

@@ -28,8 +28,9 @@ Jason's go on the professor session's brief opened #1504: seat registration.
 leaves one record at `<dataRoot>/seats/<layout>/<seat>/registration.json` that the
 board reads instead of guessing; `scripts/mosaic seat task <seat> <text>`
 changes the task. The four repository launch scripts register themselves.
-Package: `packages/seat`. Fleet launchers under `~/.mosaic` are not edited
-from this repository; the one-line change for them is in the plan page.
+Package: `packages/seat`. Fleet seats stay on their own launchers (Jason's
+ruling, 2026-09-12); only `agents/` seats register. A record whose pid is
+gone is stale and does not override the derived values.
 
 Next action: step 3 of #1503 continues — daily use with #1504 landed. Jason
 launches his seats through the new path (or the launch scripts, which now