[Bug]: t3 doctor --fix cannot get its exclusive lock when a desktop app on another machine relaunches the stopped server over SSH #24318

Area

apps/desktop (remote launch) and apps/server (t3 doctor)

Version or commit

t3 v0.1.2-nightly.20261022.3541

Environment

macOS 27. A headless t3 serve runs as a launchd service. A desktop app on another machine connects to it over SSH and can launch the server through the host's ~/.t3/ssh-launch/ script.

What happened

t3 doctor --fix needs BEGIN EXCLUSIVE with busy_timeout = 0. After the service was stopped for maintenance, a new t3 serve was started through the SSH launcher about 11 seconds later, and that server opened the database. Times are relative to stopping the service:

• T+0 s: the service was stopped. At T+8 s and T+23 s, t3 doctor --fix stopped with DatabaseInUseError. The SSH-launched server, started at about T+11 s, held the database.
• About T+5.5 min: a second attempt stopped the same way, about 1 second after it started.
• About T+6.5 min: a third attempt stopped the service, sent SIGTERM to the SSH-launched server, and started the doctor within 2 seconds of its exit. It ran for 51 minutes and exited 0.

Steps to reproduce

1. Run t3 serve as a service on host A, with the desktop app on machine B connected to A over SSH.
2. Stop the service on A, and run t3 doctor --fix within a few seconds.
3. The server is relaunched on A through the SSH launcher, and the doctor fails with DatabaseInUseError.

Expected behavior

t3 doctor holds off competing launches while it runs (for example with a maintenance lock file that the SSH launcher respects), or at least names the process that holds the database.

Actual behavior

The doctor fails without changing anything. The host then serves from a server that the service manager does not own, until someone stops it.

Workaround

Stop the service, stop any SSH-launched t3 serve on the host, then start t3 doctor --fix immediately.