Daemon doesn't auto-recover after shutdown-requested control-socket op - ~62 min outage kills Desktop Remote Control

Environment:

• Claude Code CLI 2.1.201 (auto-updated from 2.1.200 mid-session)
• Windows 11 Home 10.0.26200
• Claude Desktop: classic (non-MSIX) install, AppData\Local\AnthropicClaude
• Backend: on-demand/transient daemon (Windows)

Summary:
The background daemon received an explicit shutdown request and never restarted on its own. For ~62 minutes, no daemon process existed at all - not hung, not slow, simply absent. This silently broke the Desktop app's "Remote Control" bridge to a terminal-side session; Desktop only surfaced a generic "Remote Control disconnected - check your terminal for errors" banner, which is misleading since the terminal wasn't the problem.

Timeline (from daemon.log, local time UTC-5):

6:01:53 PM  supervisor: binary at .local/bin/claude.exe changed (mtime changed) - self-restarting for upgrade
6:01:54 PM  daemon start, version=2.1.201 (two competing starts, one wins lock race, one exits cleanly)
6:04:31 PM  worker settled (killed) - normal cleanup post-upgrade
6:20:17 PM  supervisor: shutdown requested via control socket
6:20:17 PM  supervisor: shutting down (cause=shutdown_op, uptime=1103s, leases=0, live_workers=2)
            [[ NO DAEMON RUNNING FROM HERE... ]]
7:22:40 PM  supervisor: daemon start, version=2.1.201 (origin=transient)
            bg adopt: adopted=0 respawned=0 dead=4   <- prior workers all found dead, none recovered
7:24:04 PM  fleet worker respawned
7:29:43 PM  first successful response to a queued message

That's a 62-minute gap with zero daemon process alive, and no user-visible recovery - something eventually triggered a fresh daemon start (likely a new CLI invocation), but nothing proactively restarted it after the shutdown, and Desktop gave no indication of how long it had been down or that a retry might now work.

Expected: either (a) the on-demand daemon respawns automatically on next control-socket activity without a dead window, or (b) if a shutdown_op is intentional (e.g., triggered by an update or explicit stop), Desktop's Remote Control should reflect that state distinctly from a crash, and/or auto-retry once a daemon becomes reachable again instead of requiring a manual "Try Again."

Actual: silent ~1 hour outage, generic/misleading disconnect message pointing at "your terminal," manual retry required with no signal that the backend had recovered.

Related: this looks like the same family of issue as the previously-reported stale-daemon.lock PID-reuse deadlock, but distinct - no stale lock was involved here, just a shutdown with no self-healing restart trigger.