Remote Control: session permanently wedged when worker dies unregistered (phantom worker_status:running); still reproduces on 2.1.259 (re-file of #76530)

## Summary

Re-filing #76530, which the stale bot closed on 2026-09-03 without any maintainer response. The bug is unchanged and still reproduces on current CLI 2.1.259 (Windows 11, Desktop 1.40609.1, iOS app).

When a Remote Control worker dies without deregistering (crash, hard kill, power loss, Desktop app exit) while a turn is in flight, the session is left phantom server-side: `worker_status: "running"` + `connection_status: "disconnected"`, indefinitely (observed 3+ hours, no TTL). New prompts from the mobile app are accepted as events but never dispatched to a new worker. The card spins forever. Stop + reprompt does nothing. Restarting the `claude remote-control` daemon revives cleanly-disconnected sessions but not this one.

Full repro, dead-end matrix, and root cause are in #76530 and still accurate. Short version of the root cause: `worker_status` is entirely client-authored (`PUT {sdkUrl}/worker`), so when the worker dies without writing a terminal state nothing server-side ever reconciles it against the dead transport, and dispatch keeps treating the session as served.

Related: #37321 (closed not planned), #60790, #52860.

## New evidence since the original report

I run a local supervisor that polls my own sessions and detects this exact signature (`worker_status=running` + `connection_status=disconnected`). Since filing on 2026-07-10 it has caught and recovered 15 phantom sessions across 7 separate days, most recently 2026-08-28:

```
2026-08-17 16:19:53 phantom detected: cse_01S4EFQx3xQhTeqCuiuzjm6m (worker_status=running, disconnected) -> reviving
2026-08-25 17:36:49 phantom cse_01XhCYU8R5wow1ppcpQsRaVV: revived via bridge epoch 2
2026-08-25 17:36:50 phantom cse_01FkrcJHpn2X8HiFGd4qpMBB: revived via bridge epoch 2
... (5 more the same minute; one Desktop app exit orphaned 7 sessions at once)
2026-08-28 13:50:26 phantom cse_012MNrvRhMNrGWtahcGbWAq7: revived via bridge epoch 2
```

The common trigger is mundane: the Desktop app exits or crashes and takes the worker processes with it. No exotic kill needed. Every Desktop death with in-flight turns produces phantoms.

## Recovery that works (still undocumented)

The epoch takeover already exists in the client; it is just not exposed. This is what the supervisor automates:

1. `POST /v1/code/sessions//bridge` (OAuth bearer, `anthropic-version: 2023-06-01`, `anthropic-beta: ccr-byoc-2025-07-29`, body `{}`) returns `{worker_jwt, worker_epoch, ...}`. The fresh epoch supersedes the phantom.
2. Spawn a worker with the JWT via env vars, the same way the daemon does: `CLAUDE_CODE_SESSION_ACCESS_TOKEN=`, `CLAUDE_CODE_WORKER_EPOCH=`, `CLAUDE_CODE_SESSION_ID=`, `CLAUDE_CODE_ENVIRONMENT_KIND=bridge`, then `claude --print --sdk-url https://api.anthropic.com/v1/code/sessions/ --session-id `.

The worker attaches, resumes the interrupted turn (including re-requesting the in-flight tool permission), and the card goes `connected` / `requires_action` with history intact. 15 for 15 on the recoveries above.

## Asks (unchanged)

1. **Server-side reconciliation**: `connection_status: disconnected` for more than N minutes should clear `worker_status` so normal dispatch resumes. This alone fixes the user-facing symptom.
2. **Expose the takeover**: `claude remote-control --reconnect ` doing the bridge claim above (and reconciling the local bridge-pointer lock) makes recovery a one-liner.
3. **Document an escape hatch**: even `POST /archive` (works, 200/409, force-closes a dead card) is absent from the Remote Control docs.

Session IDs and request IDs available on request.

Start with the full repro and root-cause matrix in #76530, then reproduce the worker_status=running and connection_status=disconnected signature. Trace the Remote Control daemon, the PUT /worker flow, and the POST /bridge and /archive endpoints. Done would require an agreed scope and a verified fix or documented recovery path that prevents or clears phantom sessions.

Vom Indexierungsmodell aus dem Issue-Text verfasst.