Fix background start falsely reporting success when the server fails to start

[kiakiraki]

Problem

When starting a server in the background, waitForReady treats any HTTP 200 on /_/api/status as "ready" — a JSON decode failure is even short-circuited to success (return nil, nil //nolint:nilerr) — and it never verifies that the spawned child is the process actually serving the port. Combined with the probe→listen TOCTOU in the CLI, this produces false success reports in three related ways (all reproduced on Linux):

1. Concurrent startup race loses files silently. Two mo invocations on the same port both pass the ~500ms probe and both spawn a server. The loser's child dies with EADDRINUSE, but the loser's parent receives the winner's status, prints mo: serving at ... (pid <dead pid>) with the winner's deeplinks, and exits 0. The loser's files are opened nowhere. Realistic triggers: git ls-files '*.md' | xargs -n1 mo, editor integrations, or a loaded machine where the existing server's probe response exceeds 500ms.
2. A non-mo server occupying the port also yields exit 0. If whatever is listening returns 200 to /_/api/status, mo reports success although the child died and the port owner is unchanged. If it returns non-200, the user gets a misleading "check log file" timeout after 10s.
3. The child's fatal error is unrecorded. Cobra writes RunE errors to stderr, which is /dev/null for background children, so cannot listen on ...: address already in use appears nowhere — the log only shows a secondary shutdown error: context deadline exceeded, caused by watchLoop never exiting on the listen-failure path (its exit depends on watcher.Close(), whose cleanup hook is registered only after a successful net.Listen).

Fix

• waitForReady only treats a response as ready when the status decodes and carries a non-empty version (same validation as probeServer). It also takes the spawned child's PID:
  • If a mo server responds with a different PID, it returns errServerConflict with the winner's status. startBackground then falls back to POSTing the requested files/patterns/uploads to the winning server (server-side AddFile is idempotent for duplicate paths), and errors out if nothing could be added instead of claiming success.
  • If the child dies, it fails fast after a 1s grace period (giving a race winner a moment to start serving) instead of waiting out the full 10s. Child death is detected with a non-blocking wait4 on Unix, because the unwaited child remains a zombie for which kill(pid, 0) still succeeds. On Windows, os.FindProcess is used best-effort; PID reuse degrades gracefully to the old full-timeout behavior.
  • The timeout message now points at the likely cause: the port may be in use by another (non-mo) server.
• The restore file is only removed once the child is confirmed dead — a slow-but-alive child may not have consumed it yet.
• Fatal RunE errors are slog.Error'd before the log file closes, so the root cause lands in mo-<port>.log. This is only registered when logging to a file, avoiding duplicate stderr output in --foreground mode.
• On listen failure, startServer closes the watcher so watchLoop exits and donegroup cleanup no longer times out after 5s.
• The race-lost fallback gates openBrowser on isNewGroup || open, matching the existing add-to-running-server path.

Known limitations (accepted): a server self-restart during the 10s polling window would be classified as a conflict (benign — the fallback POST is idempotent and the files still end up served), and Windows PID reuse can defeat the fail-fast (falls back to the previous timeout behavior).

Behavior before / after

Concurrent race (mo -p 17700 race-a.md and mo -p 17700 race-b.md simultaneously):

# before (loser's output): false success, race-a.md lost, pid is a dead process
mo: serving at http://localhost:17700 (pid 23511)   # deeplink shows race-b.md

# after (loser's output): files added to the winner, nothing lost
mo: another mo server is already running at http://localhost:17700 (pid 49352); added 1 item(s) to it

Non-mo server on the port (python3 -m http.server variant returning 200):

# before: exit 0, "serving at ..." with a dead pid, empty log
# after: exit 1 in ~1.1s, and the log records the root cause
Error: server process exited unexpectedly; the port may be in use by another server (check log file for details) (spawned pid 48885)
# mo-17662.log: "cannot listen on localhost:17662: ... address already in use"

Tests

• TestWaitForReady_Success / TestWaitForReady_PIDMismatch / TestWaitForReady_NonMoServer / TestWaitForReady_ChildExited — ready validation, conflict detection, non-mo rejection, and fail-fast on child death (zombie-based, deterministic).
• TestProcessAlive_ZombieChild — regression for the zombie case: kill(pid, 0) succeeds for an unwaited dead child, so processAlive must reap.
• TestAddToRunningServer / TestAddToRunningServer_AllPostsFail — fallback POSTs and the all-failed error path.
• Unix-specific tests are skipped on Windows.

Verification

• go build ./..., go test ./... -race, golangci-lint run / gostyle: clean.
• Both failure scenarios reproduced on the parent commit and verified fixed end-to-end with the built binary (isolated XDG_STATE_HOME, ports 17xxx), including log contents and exit codes.

Reported in kiakiraki#2 (with full reproduction steps).

🤖 Generated with Claude Code

[k1LoW]

@kiakiraki Thank you!!