bug(serve): omni-bridge stays stopped after daemon restart (#1485 sibling)

[namastex888]

Summary

Per dog-fooder-b367 verdict 2026-04-29: "post-kill serve recovery degraded with omni-bridge stopped". After genie serve stop + genie serve start, omni-bridge does NOT restart automatically — it remains in stopped state until manually triggered.

Repro

1. genie serve start → omni-bridge running
2. genie serve stop → all subsystems halt
3. genie serve start → daemon comes back, but omni-bridge stays stopped
4. genie serve status confirms omni-bridge: stopped

Why it matters

Operators expect daemon restart to be a clean recover-all. omni-bridge being silent means whatsapp/telegram/etc routing breaks invisibly until someone notices messages aren't flowing.

Evidence: /home/genie/workspace/agents/genie/.genie/agents/dog-fooder/state/repro-1485/

[namastex888]

Triage @ 2026-04-30 — STILL-OPEN-CONFIRMED

Tested against: chore/pgserve-2.0.2 HEAD 4b5e1820 (chore(version): bump to 4.260429.33 [auto-version])

Evidence:

Root cause is visible in dog-fooder evidence at .genie/agents/dog-fooder/state/repro-1485/serve-background.err:

Omni bridge: degraded — [omni-bridge] pidfile locked at /home/genie/.genie/state/omni-bridge.json: pidfile locked by PID 1822343

Code path on current dev branch:

• src/services/omni-bridge.ts:347-391 — claimPidfile() calls evictStalePidfile(), which only unlinks the bridge pidfile when the recorded PID is dead (isPidAlive returns false via kill(0) → ESRCH). If the stale PID has been recycled to any live process — common after a serve stop + serve start cycle — the new bridge throws pidfile locked by PID <pid> and startOmniBridgeSafely (src/term-commands/serve.ts:870-892) swallows the error as "degraded", leaving handles.omniBridge = null.
• BridgePidfile (src/lib/bridge-status.ts:21-27) only persists pid, startedAt, subjects, natsUrl — no parent-serve PID and no daemon-generation marker, so the new bridge cannot tell "this pidfile belongs to a dead generation of serve" from "this pidfile is genuinely owned by a live peer bridge".
• stopServe (src/term-commands/serve.ts:1253-1316) SIGTERMs the serve process group with a 10s deadline, then SIGKILL. SIGKILL bypasses the bridge's signal-handler pidfile cleanup at omni-bridge.ts:429-435, so any forceful stop leaves the pidfile behind.
• No commits on main or chore/pgserve-2.0.2 since 2026-04-29 touch this code path (git log chore/pgserve-2.0.2 -- src/services/omni-bridge.ts src/lib/bridge-status.ts confirms the most recent omni-bridge commit, 3562f2df, is per-chat session persistence — unrelated).

Status check from same evidence (serve-status-after-kill-restart.out): omni-bridge: stale — ping failed: 503 after restart, then omni-bridge: stopped in the final status (summary-evidence.txt:44).

Verdict: STILL-OPEN-CONFIRMED

Suggested fix direction (not implemented in this triage): either record the parent serve PID in the bridge pidfile so the new bridge can evict pidfiles whose parent serve is dead, or have stopServe proactively unlink ~/.genie/state/omni-bridge.json after the daemon process group is reaped.