Cross-process session concurrency: two processes can run loops on the same session simultaneously

Bug

\packages/opencode/src/session/run-state.ts\ keeps its per-session Runner map in \InstanceState\ — in-memory, per-process. When two opencode processes share the same session database (e.g., a TUI and a headless \opencode serve, or two TUI windows), both can start agent loops on the SAME session concurrently, producing interleaved parts from two different message streams.

Reproduction

1. Open a TUI attached to session X
2. Start \opencode serve --port N\ on the same project
3. POST to /session/X/message on the serve port while the TUI is mid-turn
4. Both processes run loops on session X simultaneously — interleaved step-start/step-finish parts from different runs

Evidence

From opencode.log, two concurrent run IDs (3f40dbfe and 20413a5b) produced interleaved loop/process/stream lines on the same session for 16 minutes.

Proposed fix

Persist the runner state (a DB-level lease or advisory lock keyed by session ID) so only one process may run a loop on a session at a time. The second process should either join the running loop or queue until it finishes.

Impact

Interleaved parts from concurrent loops create confusing output, phantom assistant messages responding to partial state, and data corruption risk when both loops write to the same message rows.