[Bug]: With a shared $HOME, a server on another machine is reported as "no running server", and the advice given would break that machine #34054

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Two Linux machines share one NFS $HOME (e.g. an HPC login node and a compute node), with lingering enabled on both.

1. On host A, run t3 up. The service starts and owns ~/.t3/userdata (server-owner.sqlite, server-runtime.json).
2. On host B, systemd --user reads the same ~/.config/systemd/user/t3code.service, so a launcher starts there against the same ~/.t3.
3. On host B, run t3 pair.
4. On host B, run t3 serve.
5. On host B, run t3 up --base-dir ~/.t3-hostB.

Expected behavior

t3 recognizes that ~/.t3 is owned by a live server on another machine and says so, e.g. "A T3 Code server on host A owns this T3 home. To pair with it, run t3 pair there. To run a server on this machine, use a separate T3 home." Its advice should not stop or remove host A's service.

Actual behavior

• t3 pair (step 3) reports NoRunningServerError: No running T3 Code server found. discoverPairTarget reads server-runtime.json and checks its PID with isProcessAlive on the local machine. The PID belongs to host A, so the live server is treated as gone. If that PID number happens to be in use on host B, t3 pair instead probes 127.0.0.1:<port> on host B.
• t3 serve (step 4) fails with ServerAlreadyRunningError ("Stop that server…"), and host B's launcher logs Another T3 Code server owns this T3 home. Stop it, then restart this service. That server can't be stopped from host B, and nothing names the machine it runs on. Meanwhile t3 up on host B reports the service as running, although its launcher can't start a server.
• t3 up --base-dir ~/.t3-hostB (step 5) fails with BootServiceOtherBaseDirError, which suggests t3 service uninstall --base-dir '/home/<user>/.t3'. Since fix(server): t3 service uninstall leaves another T3 home's service alone #29872 that command stops and removes any unit serving ~/.t3. On a shared $HOME, that's the one unit both hosts use, so following the advice takes host A's service down.

Neither server-runtime.json (pid, port, origin, ownerId, …) nor the owner lock records which machine the owner runs on, so these paths can't tell "dead process" from "live process on another host".

Impact

Major degradation or frequent failure

Version or commit

0.1.8

Environment

Rocky Linux 9, systemd 252, NFS-shared $HOME, lingering enabled

Logs or stack traces

$ t3 pair
ERROR (#2): NoRunningServerError: No running T3 Code server found.
  checked /home/<user>/.t3/userdata/server-runtime.json
  checked /home/<user>/.t3/dev/server-runtime.json
Start one with `t3 serve`, or connect this machine with T3 Connect: `t3 connect`.

$ t3 serve
ERROR (#2): ServerAlreadyRunningError: A T3 Code server already owns /home/<user>/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. No server was stopped. server-owner.sqlite is the ownership lock; do not delete it while a server is running.

# host B launcher, in ~/.t3/userdata/logs/boot-service.log
[service-launcher] Another T3 Code server owns this T3 home. Stop it, then restart this service.

$ t3 up --base-dir "$HOME/.t3-hostB"
ERROR
  The T3 Code service on this machine serves /home/<user>/.t3, not /home/<user>/.t3-hostB. Pass --base-dir '/home/<user>/.t3' to manage it, or run `t3 service uninstall --base-dir '/home/<user>/.t3'` first to move it; both data directories are kept.

Workaround

A per-host systemd drop-in plus a hand-built runtime/ in a second T3 home. Details are in the Ideas discussion for per-host services on a shared $HOME: #34047. That discussion covers the feature; this issue covers only the detection and the advice.

A possible fix: record the hostname in server-runtime.json (and/or in the owner lock), skip isProcessAlive when it doesn't match the local host, and name that host in NoRunningServerError, ServerAlreadyRunningError, the launcher message, and BootServiceOtherBaseDirError. Those errors would then stop suggesting stop or uninstall commands that act on the other machine's service.