[Remote Control] Inbound cloud-message delivery silently dead on second machine: per-account Cowork registration conflict (409) is never surfaced, behind a bridge-state.json bootstrap catch-22

## Environment
- Windows 11 Pro (both machines), Claude Desktop app 1.40609.0, Claude Code CLI 2.1.247–2.1.250
- Same claude.ai account (Max) on two machines: **Machine A** (working) and **Machine B** (broken)
- `claude doctor` clean on Machine B; no proxy, no `ANTHROPIC_API_KEY`, no telemetry-disable env vars

## Summary
On a two-machine account, messages queued with `claude -p "" --cloud ` deliver into live desktop-session panes on Machine A within seconds, but NEVER deliver on Machine B — no error, no log line, nothing. Root cause chain (established over ~2 days of testing, full timeline below):

1. The desktop sessions-bridge (the component that drains cloud-queued messages into local panes) only initializes if `%APPDATA%\Claude\bridge-state.json` already contains `userConsented: true` for the org:account — but that file is normally only written by the bridge's own start-up. A machine that loses the file (e.g. app reinstall) can never re-create it through any user-reachable path. Settings toggle off/on, full app restarts, `/remote-control`, and fresh-session creation were all tried; none mint the file. (Related: #86084.)
2. Once the file was hand-seeded with the minimal `{enabled: true, userConsented: true}` object, the bridge initialized for the first time and immediately surfaced the real, previously-invisible blockers:
- `Cowork OAuth stale-session (session_stale_relogin); parking bridge until re-login: Session is not fresh enough to grant elevated access.` — cleared by signing out/in of the desktop app.
- Then, decisively: `Registration conflict (409): A Cowork agent is already registered on . Disconnect it there before registering this device.`
3. So inbound cloud-drain registration is a **one-per-account singleton**. Machine A registered first and works; Machine B can never receive cloud-queued messages while Machine A holds the slot. **None of this is ever shown to the user** — without the hand-seeded file the app fails 100% silently, and the drain simply doesn't happen.

Meanwhile, messages typed into the session's claude.ai/code web page DO deliver into Machine B's pane (live socket path), which is how we confirmed the rest of the pipeline is healthy.

## Repro (condensed)
1. Two Windows machines, one account, desktop app + Remote Control both apparently working ("Enabling remote control for session …", `bridge_state: connected` in main.log on both).
2. From Machine A: `claude -p "hello" --cloud ` → CLI reports "Sent to cloud session."
3. Machine B: message never prints; no `queue-operation` enqueue record in the session transcript; no error anywhere.
4. Machine B has no `%APPDATA%\Claude\bridge-state.json`; Machine A has one (created at its most recent session start). Machine B's log contains no `[sessions-bridge] Initializing bridge` / `Registering environment` lines, ever.
5. Seed the minimal file on Machine B, restart app → bridge finally initializes → stale-login park → re-login → **409 conflict naming Machine A**.

## Expected
- Either multi-machine inbound delivery works, or the limitation is surfaced: the 409 (and the stale-login park) should be shown in the UI, and the consent record should be creatable without hand-editing app state.
- At minimum: a machine whose bridge cannot start should log why at startup instead of nothing.

## Log excerpts (Machine B, after seeding the file)
```
10:13:04 [info] [sessions-bridge] Initializing bridge { oauthEnv: 'production', apiHost: 'https://api.anthropic.com', ... }
10:13:04 [info] [sessions-bridge] Registering environment (fresh)...
10:13:04 [warn] [sessions-bridge] Cowork OAuth stale-session (session_stale_relogin); parking bridge until re-login: Session is not fresh enough to grant elevated access. Sign in again to continue.
-- after desktop re-login --
10:15:30 [info] [sessions-bridge] sessionKey rotated; restarting bridge after session_stale_relogin park
10:15:30 [info] [sessions-bridge] Registering environment (fresh)...
10:15:31 [error] [sessions-bridge] Registration conflict (409): Registration: Conflict (409): A Cowork agent is already registered on . Disconnect it there before registering this device. [request-id: req_011CeZ5EgCn5qy82MWFjDxA7]
```
Before seeding the file, none of these lines ever appear — the bridge never initializes and nothing is logged.

## Related issues
- #86084 — enabled state never persisted to bridge-state.json (this report adds the bootstrap catch-22 mechanism and the reinstall-loses-file-forever consequence)
- #45946 — cloud messages never dispatched into local CLI pane (this report adds the root cause on multi-machine accounts: no bridge registration on the receiver)
- #86014 / #80311 — cross-machine session SendMessage success-but-no-delivery (reproduced here too: 8 sends, 8 success reports, 0 deliveries, transcript-verified both directions)
- #87777 / #69543 — session-level Remote Control enable skipped after app restart until first turn or manual `/remote-control` (reproduced)

## Notes
- Verified delivery by the receiver's transcript (`queue-operation` enqueue records), never by sender success reports.
- Machine B previously had a working bridge-state.json under an older install (April 2026); the app reinstall lost it, which is what stranded the machine permanently.

Start by reproducing the two-machine flow with the sessions-bridge entry point, bridge-state.json, and main.log. Check startup behavior before and after the consent file is present, then verify that stale-login and registration-conflict states are surfaced and that the result is observable without hand-editing app state.

Escrito por el modelo de indexación a partir del texto del issue.