The attach loop's PID liveness fallback used `last_seq > 0` (store path)
and `!progress_file_is_empty` (file path) to keep the engine "alive" when
no launcher record could be found. These conditions are always true once
events exist, so the loop never exited via the PID path after the launcher
record was cleaned up by start_run or active_launcher_record_for_run.
The store-based terminal status check (the other exit path) only read from
the SlateDB DbReader, which may not see data still in the WAL or not yet
visible via manifest poll. Adding a disk fallback to read status.json
ensures the check works even when the store reader has a stale view.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
e75d8a2fb0