fix(bridge): prevent process leak via PID file singleton guard

[syzsunshine219]

Summary

• Bridge processes accumulate indefinitely: each hermes chat session spawns a new bridge.cts, and the previous one stays alive as a "daemon" but is never cleaned up. On long-running servers this results in 10+ zombie bridge pairs.
• Introduces a PID file (daemon/bridge.pid) as a lightweight singleton lock. On startup, the new bridge reads the PID file, kills the stale process (SIGTERM → 5s → SIGKILL), writes its own PID, and removes it on all exit paths.
• --no-viewer (headless) bridges skip the kill — they coexist with the daemon that owns the viewer port.
• The existing install.sh kill logic is preserved as a complementary deployment-time fallback.

Test plan

• Start bridge daemon → verify daemon/bridge.pid is created with correct PID
• Start a second bridge → verify the first is killed and PID file updated
• SIGTERM the running bridge → verify PID file is removed
• Run hermes chat twice in sequence → verify only 1 bridge pair remains (no accumulation)
• Run --no-viewer bridge alongside daemon → verify both coexist (no kill)

[chiefmojo]

Large-DB crash loop: PID singleton kills old bridge before DB lock releases

We reverted a 655MB MemOS DB from v2.0.0-beta.1 to v2.0.5 and hit an infinite bridge restart cycle. The PID singleton guard kills the old bridge, but the new bridge then opens the same SQLite DB and hangs in WAL recovery — long enough to exceed the gateway's 30s timeout. The gateway spawns yet another bridge, which kills the current one, and the cycle repeats indefinitely.

On a smaller 43MB DB the same code works fine — WAL recovery completes before the next bridge spawns. The threshold where it breaks seems to be somewhere between those two, likely dependent on DB size and I/O speed.

Root cause: killExistingBridge() sends SIGTERM but doesn't wait for the old process to fully exit and release file locks. A waitpid() or polling fuser on the DB file before proceeding would prevent the race.

Cross-ref: #1452 describes a related class of startup-hang → restart-loop issues.