Phase 3: auroraview-cli run — spawn-or-join dcc-mcp-server + register CDP ServiceEntry

[loonghao]

Part of #364.

Make auroraview-cli run integrate with the dcc-mcp-core gateway so agents can discover the webview without any manual wiring.

Flow

1. Allocate a free TCP port for CDP; pass --remote-debugging-port=<port> to the embedded Chromium.
2. Probe FileRegistry for a running gateway:
   • Use dcc_mcp_transport::discovery::FileRegistry (already exposed in v0.13.2).
   • If __gateway__ sentinel is present and healthy → join.
   • Else spawn dcc-mcp-server as a detached child process, respecting first-wins election (docs: add project vision and motivation to homepage #204). Losing the race is fine; re-probe and join.
3. Register our own ServiceEntry:

   {
     "dcc_type": "auroraview",
     "pid": <our pid>,
     "socket_path": "<ipc socket>",
     "extras": {
       "cdp_port": 9222,
       "url": "file:///.../app/index.html",
       "window_title": "Launcher",
       "capabilities": { "snapshot": true }
     }
   }

4. On shutdown: deregister the entry; if we spawned the gateway and are the last adapter, terminate it.

Notes

• dcc-mcp-server binary location: resolve via which first, then fall back to an optional vendored path set at auroraview-cli install time.
• Gateway lifecycle is orthogonal to individual webview windows — opening a second auroraview-cli run just registers a second ServiceEntry; the gateway multiplexes.
• Concurrent launches are safe by construction because the gateway itself handles first-wins election.

Blocked by

• Phase 2 (#this-epic's adapter crate) for the ServiceEntry.extras schema shape agreement.