Feature request: a safe way to deregister a Dispatch host in the desktop app, and let a non-host desktop app act as a client

## Summary

The desktop app offers no way to release a device's Dispatch host registration without deleting data, and no way for a second desktop app to attach to a Dispatch session hosted elsewhere, although the web and mobile clients already do the latter.

## Request 1: a safe "release this device's Dispatch host registration" control

The only registration control in the app today is the button on the "Another device is connected" screen, "Disconnect all and retry". Its label says "all", but each press logs one deregistration:

```
[sessions-api] deregisterAll: deregistering 1 env(s)
```

Which environment that was is not in the log. The button runs without a confirmation, replaces this device's registration with a fresh one (so the existing remote session becomes unreachable), and the "Retry" button on the "Session couldn’t be created." screen that follows deletes the local workspace, transcript and memory files included, also without a confirmation. On 2026-08-17 this cost me a Dispatch session; it came back only from a prior backup and a disk rollback.

The safe action exists only outside the app: delete one specific registration through the environments API (`DELETE /v1/environments/bridge/{environment_id}`), after which the app reconnects its existing session on its own. Requested: an in-app control that shows which device holds the registration, lets the user release it, and never deletes a workspace as a side effect. Turning the Dispatch toggle off does not deregister today (it logs only a local dispose), so that toggle is not a substitute.

## Request 2: a desktop app that is not the host should act as a client

As observed on my own setup: claude.ai in a browser and the mobile app both open the Dispatch session hosted on my always-on machine, show its conversation and accept messages to it. The mobile app is a path I use daily. A second desktop app cannot; inspecting the app bundle found no client or attach mode, only the slot conflict above. Same account, same session, different client: the most constrained client can do what the most capable one cannot.

When the second app is refused, the message is:

```
A Cowork agent is already registered on . Disconnect it there before registering this device.
```

If the app on that device is closed, there is nowhere to "disconnect it there", and the only control left is the destructive button from request 1.

Requested: when a desktop app is not the registered host, let it attach to the hosted session as a client, the way web and mobile do. Read-only would already be a large step; read and send would match claude.ai.

## How the two relate

Request 2 is the root fix: a non-host app that becomes a client has nothing to compete for. Request 1 is the safety net for the times a registration really has to move. Either one alone would have prevented the 2026-08-17 loss.

## Environment

Ubuntu 26.04 desktop app (Dispatch host, orchestrator running locally), a macOS desktop app, and the mobile app on one personal account. The apps run in Korean; English strings above are from the 1.40609.1 bundle's translation catalogue.

The issue names no repository files, tests, or entry points. Start by locating the desktop Dispatch registration flow and its environments API integration, then trace the host-conflict and retry paths. Done means a non-host desktop can attach safely and users can release one registration without deleting workspace data.

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