fix(cli): elect one managed daemon

[kitlangton]

Addresses #35801

Prerequisite for #35646.

Summary

• acquire a channel-scoped process-lifetime lock before service routes are constructed
• make concurrent losing service candidates exit cleanly instead of briefly serving and replacing registration
• add non-blocking EffectFlock.tryAcquire with scoped release and heartbeat
• reclaim crashed same-host owners immediately when their PID no longer exists
• retry election briefly while a displaced owner tears down

Why

Service registration currently happens after route construction, so concurrent starts can create several live daemons before registration eventually selects one. Session restart recovery needs a real single-owner daemon seam before it can safely start work.

The registration file remains client discovery. The lifetime lock establishes which process may construct and serve the managed daemon.

Verification

• concurrent subprocess test launches two serve --service candidates and verifies one registered healthy owner remains
• EffectFlock tests cover non-blocking contention and immediate crashed-owner recovery
• bun typecheck in packages/core and packages/cli
• file-scoped Prettier and oxlint
• pre-push full repository typecheck: 31 packages passed

Follow-up

A separate recovery-inbox change can now start only from the elected daemon and avoid scanning historical Session events.

• This does not implement fix(cli): recover from concurrent service replacement during startup #35801's TUI-side expectation (rediscover the winning registration and retry initial API requests). Election removes the many-candidates race, but a TUI holding a displaced owner's transport can still fail during the handover window; that retry remains a follow-up in packages/cli/src/tui.ts.