v0.8.1: supervisor restart loses live worker active-session mapping during RLM fan-out

[Atroci]

Summary

Prime Agent 0.8.1 lost its daemon connection during an interactive RLM fan-out. The original supervisor disappeared, but its worker process and socket stayed alive. A replacement supervisor recovered that worker, then every client reconnect failed with Unknown active session.

This resembles #1221, but this incident did not follow a reboot. It happened while the machine and worker remained live.

Environment

• Prime Agent: 0.8.1
• Build: 5146337-dirty
• Protocol: 7
• Node.js: 24.15.0
• OS: Fedora Linux
• Workload: one interactive resident session admitting 16 RLM children; failure occurred around child 6

Timeline in UTC

• 20:51:26: original supervisor and worker started.
• Around 21:14: old supervisor disappeared without a shutdown record.
• 21:14:46: replacement supervisor started.
• 21:14:48: adoption timed out waiting for the surviving worker hello.
• 21:15:05: daemon logged recovery of the worker without replaying uncertain operations: rlm_child_update, agent_end, message_start, and message_end.
• After recovery: client reconnects repeatedly returned Unknown active session for the original active-session ID.

The surviving worker still owned its forkserver socket. The session transcript and completed child artifacts remained present.

Relevant log lines

Timed out waiting for adopted worker hello
Recovered worker ... without replaying uncertain operations: rlm_child_update, agent_end, message_start, message_start, message_start, message_end
Daemon reconnection failed: Unknown active session
Cannot send daemon command "prompt" because the Prime Agent daemon is not connected

Checks performed

No matching kernel OOM, systemd-oomd, earlyoom, coredump, reboot, package update, or recorded system signal was found at the incident time. This does not establish why the original supervisor exited. The fan-out is correlated with the failure, not proven as its cause.

prime-agent doctor --fix --json later found the replacement default daemon healthy and reaped nothing.

Expected

Per the daemon recovery design, a replacement supervisor that adopts a live worker should restore a usable binding for the existing active-session ID, or return a structured replacement ID that the client can rebind to.

Actual

Worker recovery completed, but the previous active-session ID was absent from the new supervisor. The client kept retrying the stale ID and could neither prompt nor attach to the recovered session.

Suggested fix and regression test

1. Persist or reconstruct the active-session-to-worker mapping during adoption.
2. If the old ID cannot be restored, return a structured rebind target instead of only Unknown active session.
3. Treat repeated unknown-ID reconnects as terminal and offer attach/resume, rather than retrying indefinitely.
4. Record supervisor exit signal or status when observable.
5. Regression test: terminate only the supervisor while a live worker has in-flight rlm_child_update and message_start operations, start the replacement, then reconnect with the previous active-session ID.

Workaround

I preserved the transcript, left the broken session behind, and moved the fan-out to a bounded outer orchestrator with three concurrent workers. I did not apply an unsupported package patch or a heap-size workaround because the surviving worker and absence of OOM evidence do not support a worker heap failure.