plugin start moves the app to another port when its own server holds the port and herdr is unreachable #428

What happens

Since #415 (v0.3.49), a start that finds the port taken waits for a server that is still coming up and then, with no PORT set, moves to the next free port and keeps it. The same path runs when the port is held by our own server whose herdr has gone away: the app is moved to another port, and the message blames another program.

Reproduced with the v0.3.49 tree, a scratch HOME and plugin state dir, HOST=127.0.0.2 and a herdr test session:

1. bun scripts/plugin.ts start: "herdr web ui listening at http://127.0.0.2:7317".
2. Stop that herdr session. The server stays up and /api/health answers 502 connect_failed.
3. bun scripts/plugin.ts start again. It took 40 s and exited 1, after printing
   port 7317 on 127.0.0.2 cannot be opened: another program has it. Using port 17317 instead; …
   and then server did not answer http://127.0.0.2:17317/api/health within 20s.
   Afterwards plugin-port held 17317, the pid file named the new launcher, and both launchers were alive.
4. Start herdr again: port 7317 answered 200 again, port 17317 did not answer.
5. bun scripts/plugin.ts stop stopped the second launcher only. The first kept serving 7317 while plugin-port still said 17317.

Not observed: what status, pair and phone print afterwards (they read the kept port) and what the next start does. The same sequence was not run on v0.3.48; reading the code, it did not move the port there.

It needs start to run while the app is alive and herdr has been unreachable for 20 s. herdr's own startup hook runs with herdr up, so this should be rare.

Where

scripts/plugin.ts, settlePort(): the wait loop ends at its deadline with recordedPid() still alive and falls through to freePort. The supervisor lock is per port (updateStateDir(root, port) in server/supervisor.ts), so the launcher on the fallback port is not stopped by it.

Options

1. At the deadline, when the recorded pid is alive, treat the port as ours: fail with the pid and the address instead of moving, and leave plugin-port alone.
2. Tell "our server, not healthy" from "another program" before picking a port, for example by asking /api/health?scope=bridge, which answers without herdr.

Related, older than #415

start writes server.pid right after the spawn (that line is unchanged by #415). When the child dies on the supervisor lock ("Another server is starting. Try again."), the pid file names a dead process, and stop then prints "herdr web ui is not running" while the first launcher is still alive and still holds the lock. Seen with a herdr that was unreachable from the first start on.