Background/detached sessions die permanently after daemon restart: stale workers refused respawn, then reported dead (respawned=0)

Bug

Detached / background sessions die permanently instead of continuing: after a daemon self-restart (triggered by the CLI binary symlink changing version), the new daemon marks existing background workers "stale", refuses to respawn them, and on the next restart reports them dead without respawn. From the user's perspective, pressing ← to detach (or any handoff of a foreground session to the background daemon) kills the workflow — it must be manually restarted every time.

Related feature request about the ← gesture itself: #84348. This bug is what makes the accidental gesture destructive rather than benign.

Evidence (~/.claude/daemon.log, verbatim)

[2026-08-05T23:58:34.350Z] [supervisor] ─── daemon start ─── version=2.1.222 pid=3569272 origin=transient
[2026-08-05T23:58:34.483Z] [bg] bg adopt: adopted=0 respawned=0 dead=2
[2026-08-05T23:59:34.474Z] [supervisor] binary at ~/.local/bin/claude changed (…/2.1.222 → …/2.1.223) — self-restarting for upgrade
[2026-08-05T23:59:34.476Z] [supervisor] shutting down (cause=upgrade, uptime=60s, leases=2, live_workers=2)
[2026-08-05T23:59:34.710Z] [bg] bg adopt: adopted=2 respawned=0 dead=0
[2026-08-05T23:59:49.733Z] [bg] bg: post-takeover prewarm burst — respawned 0/2 stale workers, 2 refused in 0s
[2026-08-06T00:18:34.725Z] [supervisor] binary at ~/.local/bin/claude changed (…/2.1.223 → …/2.1.222) — self-restarting for upgrade
[2026-08-06T00:19:35.256Z] [supervisor] binary at ~/.local/bin/claude changed (…/2.1.222 → …/2.1.223) — self-restarting for upgrade
[2026-08-06T00:19:51.007Z] [bg] bg: post-takeover prewarm burst — respawned 0/2 stale workers, 2 refused in 0s

Sequence: workers alive (live_workers=2) → daemon restarts on a binary version change → adopted but considered stale → prewarm respawn refused (respawned 0/2, 2 refused) → next daemon start finds dead=2, respawned=0. No automatic recovery ever occurs; claude respawn <id> is required manually per session.

Aggravating factor: version flapping between concurrent sessions

With more than one interactive session running during an auto-update, the still-running old-version instance re-points the shared ~/.local/bin/claude symlink back to its own version (observed 2.1.223 → 2.1.222 → 2.1.223 within one minute above). Each flip restarts the daemon, and each restart re-rolls the stale-worker dice. Concurrent sessions of mixed versions are normal for long-lived background work, so this compounds the primary bug.

Expected

• Adopted workers survive daemon takeover, or are respawned automatically (respawned 2/2), preserving the session so it can be re-attached.
• A refused respawn should surface to the user and retry, not silently strand the session until it is reported dead.
• The binary-change watcher should not treat a symlink flip caused by a concurrent older instance as an upgrade↔downgrade loop.

Environment

• Claude Code 2.1.222/2.1.223, Linux (Debian), bash; background sessions via the bg daemon (backend: daemon), multiple concurrent sessions