Remote tunnel service status client can take over tunnel ownership

Type: Bug

When Remote Tunnel Access is enabled as a service, the desktop shared process starts a second `code-tunnel tunnel` process so the UI can stream the installed service singleton's logs and machine status. That process is intended to be a client only.

Current behavior

The coordinator launches the status client with normal hosting arguments, including `--name`, `--user-data-dir`, and `--delegate-to-editor`. When it connects to the service singleton, the CLI warns:

```text
Command-line options will not be applied until the existing tunnel exits.
```

More importantly, `serve_with_csa()` loops back through `acquire_singleton()` after a disconnect. During a service restart, the UI status client can acquire the singleton lock and become the tunnel owner. In a live trace this temporarily changed the hosted tunnel tags from the persisted service name to the desktop-derived hostname; after launchd recovered ownership, the tags changed back. The UI process is also parent-bound, so this defeats the service lifetime contract.

Expected behavior

The desktop child used for service status must only attach/retry as a client and must never acquire tunnel ownership. It should not pass hosting arguments that an existing singleton cannot apply. The UI should report the name emitted by the running service, not the ignored requested name. If service installation fails, the existing named in-session hosting fallback should remain intact.

Competing explanations checked

- No `remote.tunnels.access.hostNameOverride` or related remote-tunnel setting is configured in the affected profile/workspace.
- The differing requested name is the normal hostname-derived default; the installed service has its own persisted tunnel identity.
- This is built-in Remote Tunnel Access behavior, not a conflict between installed Remote Tunnel extensions.
- The service itself remained healthy and connected; deleting the desktop child would regress UI readiness/status reporting.

Source boundary

- `src/vs/platform/remoteTunnel/node/tunnelProcessCoordinator.ts` constructs the service status child as a normal hosting command.
- `cli/src/commands/tunnels.rs` uses the same acquire-or-host loop for both actual hosts and attached status clients.

Reproduced in VS Code 1.133.0. The same argument/ownership path is present on current `main` (1.135.0).

Read src/vs/platform/remoteTunnel/node/tunnelProcessCoordinator.ts to inspect how the service status child is launched, then trace the acquire-or-host loop in cli/src/commands/tunnels.rs. Verify that the status child attaches and retries without acquiring ownership or applying hosting arguments, while the named in-session hosting fallback still works and the UI reports the running service's name.

Written by the indexing model from the issue text.