Remote Control: bridge sessions permanently orphaned when their worker dies abruptly (initialize never re-spawns a worker)

Environment: Windows 11, Claude Code 2.1.201/2.1.211 (npm), always-on claude remote-control --name "..." --spawn same-dir --capacity 32 servers on a self-hosted machine; clients are claude.ai/code web/mobile.

Summary: When a remote-control worker process (claude --print --sdk-url .../v1/code/sessions/cse_...) dies abruptly — host reboot, server process kill — its session is sometimes left in a state where it can never get a worker again. The session still shows status: active with environment_id set; the client can open it and send messages (control_request initialize and user events appear in /v1/code/sessions/<id>/events, unread flips true), but no worker is ever spawned for it again, so the chat is silently dead forever. Meanwhile brand-new sessions on the same server spawn workers within seconds, and other pre-existing sessions re-attach fine — so it's a per-session stuck state, not a server-side outage.

Reproduction pattern observed (multiple incidents, 2026-07-14 → 07-19):

1. Sessions active on a remote-control server; workers alive.
2. The machine reboots (or the server process is killed) — workers die abruptly.
3. Server relaunches cleanly. User opens each chat: most re-attach and respond; a subset (2–5 per event in our fleet of ~10) never do. Their event streams show repeated client initialize with no worker-sourced response, indefinitely (hours+, across further server restarts).
4. No recovery path found box-side: restarting the server doesn't help; claude remote-control --session-id <cse> fails with Session <cse> has no environment_id. It may never have been attached to a bridge. for some, or simply nothing attaches; --resume <uuid> --remote-control mints a NEW session rather than re-attaching.

Expected: a client initialize on an active session whose worker is gone should always cause the connected environment's server to spawn a fresh worker (or the session should be marked disconnected so clients know).

Asks: (a) re-attach or time out the stale worker-attachment state server-side; (b) failing that, expose the stuck state (e.g. worker_status) so tooling can detect it, and/or provide a supported "force re-attach" for an active session.

Happy to provide session ids / timestamps privately for tracing.