feat(pull): interactive turns first, one turn per conversation (#2842, #2843)

[obasilakis]

Summary

• feat(pull): interactive turns jump the queue — the starvation half of Open Question 7 #2842: the pull claim takes interactive rows (pull_pilot.INTERACTIVE_TRIGGERS) before autonomous ones, oldest first within each group. Strict precedence, no anti-starvation rule (by decision, recorded on feat(pull): interactive turns jump the queue — the starvation half of Open Question 7 #2842): steady chat that fills every worker is answered by raising the worker count. No worker is reserved (one of N idle is 33% of a 3-worker agent).
• feat(pull): one turn per conversation at a time — the transcript-safety half of Open Question 7 #2843: the pull claim skips a row whose conversation_key already has a running row, so a busy conversation never blocks the rest of the queue. The partial unique index idx_executions_one_running_turn stops two concurrent claimers of one conversation; every transition out of running (terminal, lease expiry, requeue) releases it, so there is no lock to leak.
• conversation_key is stamped at enqueue on pull-pilot agents only. The backend drain still claims plain oldest-first.
• Canary B-02 / B-08 skip a queued row that is waiting on its own running conversation.

Nothing is routed onto the queue by this PR: interactive producers still push. That is the next PR, which also carries the live parity measurement and the transcript-burst check.

Changes

• db/schedules/queue.py — claim ordering, conversation skip, IntegrityError retry; conversation_key on the enqueue transition
• db/schema.py, db/tables.py, db/migrations.py, Alembic 0083_execution_conversation_key — column + partial unique index, both tracks
• services/pull_pilot.py (INTERACTIVE_TRIGGERS), services/pull_coordination_service.py, services/backlog_service.py
• canary/snapshot.py, canary/invariants/b02_no_queued_without_slots_full.py
• Docs: PULL_MIGRATION_STATUS.md, architecture/execution.md, feature-flows/persistent-task-backlog.md, learning fragment, /cso --diff report (0 findings)

Test Plan

• cd tests && pytest unit/test_2842_2843_pull_claim_order.py -v — SQLite and PostgreSQL (TEST_POSTGRES_URL); includes an 8-thread concurrent claim on PG
• Mutations: unique index dropped → concurrent PG test red; ordering disabled → red; conversation skip disabled → red
• Pull, backlog, canary, schema-parity suites pass on both backends
• alembic upgrade head on a fresh PostgreSQL reaches 0083; check_alembic_heads + check_alembic_parity pass
• Full unit suite: 24 failures, identical on clean dev (IPv6/SSRF address tests under local Python 3.11)

Fixes #2842
Fixes #2843

🤖 Generated with Claude Code

[dolho]

Reviewed the claim path, both migration tracks, the canary changes, and the enqueue stamping. LGTM. Approving; the notes below are non-blocking.

What I checked

• Claim correctness. With conversation_key IS NULL, the NOT EXISTS correlation evaluates to NULL, so ungrouped rows are never skipped. On PG, SKIP LOCKED lets two claimers lock different head rows of the same conversation. The partial unique index then makes the second commit raise IntegrityError, and the retry's NOT EXISTS sees the winner. Each attempt opens its own begin(), so nothing is retried inside an aborted transaction. On SQLite, writers are serialised, so the skip alone is enough there.
• The guard can't leak. It is keyed on the row's own status = 'running', so terminal, lease-expiry, and release_claim_to_queued all free it with no extra bookkeeping.
• Dual track. The SQLite migration, the Alembic 0083 revision (chained off 0082_agent_sync_state_divergence), the schema.py DDL, and the tables.py Index (declared so autogenerate won't propose dropping it) all agree.
• Scope. Keys are only stamped for pull pilots, and drain_next already refuses pilots (#1766), so the backend drain never sees a keyed row. The canary B-02/B-08 skip matches the claim's skip.

Non-blocking notes

1. De-piloting with keyed rows still queued. If an agent leaves the pilot while keyed rows are queued, drain_next claims with no NOT EXISTS. A queued turn whose conversation is still running then hits the index 3 times, gets None, and the head row blocks drain until that turn finishes. It clears itself, but the IntegrityError branch returns silently. A logger.info there would make that stall visible.
2. Push-path running rows carry no key. Interactive turns still arrive by push, and those running rows have conversation_key = NULL. Until the routing PR lands, the index only serialises queued-vs-queued turns of a conversation, not a pushed turn racing a queued one. The Redis session lock still covers that case today. Worth an explicit test in the routing PR.
3. Ordering and the partial index. The CASE sort key means idx_executions_queued (agent_name, queued_at) can't serve the ORDER BY, so the queue gets a sort step. That's fine at per-agent queue depths; just noting it.
4. Merge order. Several open PRs also add an 0083_* revision off the same 0082 (#3085, #3021/#3022, #2984). Whichever merges second needs its down_revision repointed, and alembic-head-watch will flag it on the next push to dev.