Fix event persistence race conditions on session resume

[olsonjeffery]

Summary

Fixes two interdependent race conditions that cause UNIQUE constraint failed: messages.project_key, messages.session_id, messages.seq errors when resuming conversations, making conversations inert.

Root Causes Fixed

1. Reader task not cancelled on resume — subscribe_and_spawn() created a new event subscription and reader task on every call but never cancelled the old one. Both ran concurrently, both trying to persist events for the same session, causing unique constraint violations. Also caused MaxListenersExceededWarning from stale SSE subscriptions.

2. next_seq() not atomic — persist_event() used a separate SELECT MAX(seq) query then INSERT, creating a race window where two calls could get the same seq value.

Changes

Phase 1: Rebase (no-op)

• Rebased worktree onto latest origin/main

Phase 2: Atomic seq generation (src/services/transcript.rs)

• Removed next_seq() function
• Inlined seq computation as a SQL subquery in VALUES, making seq generation and insertion atomic

Phase 3: Reader task cancellation (src/providers/opencode_sdk_provider.rs)

• Added reader_cancellation: Mutex<Option<Arc<tokio::sync::Notify>>> field
• Added cancel_inflight() helper that signals the old reader task to stop
• Added reader_stop.notified() branch to reader task's tokio::select!
• Updated abort_turn() and shutdown() to use cancel_inflight()

Phase 4: Surface persistence errors (conversations.rs, agent_runs.rs)

• Changed broadcast tasks from tracing::warn! + continue to tracing::error! + broadcast error event via WebSocket + break loop

Testing

• 441/441 lib tests pass
• New test_persist_event_concurrent: 20 concurrent calls produce unique seq values (no violations)
• New test_reader_task_cancellation: Notify signal correctly cancels reader task
• cargo fmt and cargo clippy clean