Root and reply threads: dedupe and enforce a unique key

[TheGreatAxios]

Fixes CL-7130 — https://linear.app/abklabs/issue/CL-7130

Problem

ensureRootThread (packages/chat/src/threads.ts:388-419) and
anchoredReplyThread (:454-495) SELECT ... LIMIT 1 then INSERT, and
workbench_threads (packages/chat/src/schema.ts:195-225) only had a
non-unique index on (tenant_id, workbench_id). Two concurrent first
writers could each insert a duplicate kind='root' row for the same
workbench, or a duplicate kind='reply' row for the same
parentMessageId, and the LIMIT 1 read with no ORDER BY then
picked one of the duplicates nondeterministically.

Change

• New migration 0025_workbench_threads_unique_key (next number after
  0023; skipping 0024 since PR Relaunch live agents when their inference credential rotates #427 already claims it as
  0024_workbench_launch_sources_digest) dedupes any existing
  duplicate root/reply threads, keeping the oldest row per key and
  repointing workbench_thread_messages.thread_id,
  workbench_messages.thread_id, and any workbench_threads.parent_thread_id
  that referenced a dropped duplicate, then adds partial unique indexes:
  UNIQUE (tenant_id, workbench_id) WHERE kind = 'root' and
  UNIQUE (tenant_id, workbench_id, parent_message_id) WHERE kind = 'reply'.
• Mirrors the indexes in schema.ts via uniqueIndex(...).where(sql\...`)`.
• ensureRootThread/anchoredReplyThread now insert with
  onConflictDoNothing (targeting the new partial indexes) and
  re-select on conflict — the same pattern reactions.ts'
  toggleReaction already uses — instead of select-then-insert. The
  existing LIMIT 1 reads got a deterministic ORDER BY created_at.

Tests

• packages/chat/test/migrations.test.ts: asserts the new partial
  indexes exist after a full migration run, and a new test seeds two
  duplicate root threads (with a message pointed at the newer one)
  before 0025 runs, then proves 0025 collapses them onto the oldest
  row and repoints thread membership.
• packages/chat/test/threads.drizzle.test.ts (new): DB-gated, races
  two concurrent ensureRootThread calls and two concurrent
  openReplyThread calls against a real Postgres pool, proving
  neither throws and both converge on one row.
• The machine this PR was built on was too loaded to run the full
  bun run check locally (it OOM-killed) — typecheck
  (bunx tsc --noEmit -p packages/chat), the focused test files above
  (unit + DB-gated with E2E_REQUIRED=1), prettier, and eslint on the
  changed files all passed locally; CI is the gate for the rest.

[TheGreatAxios]

critique · comment

Partial unique indexes plus insert-on-conflict-reselect keep one root/reply thread per key.

No uniqueness defect. This branch is stacked on #427; merge order is 427 then 435, or rebase onto main after 427.

• packages/chat/src/threads.ts — createDeliveryThread is still select-then-insert. Out of CL-7130 scope.

Walking-skeleton red on this PR is main deleting DATABASE_URL after memory-mount tests (CL-7182 / #465), not this uniqueness diff.

[TheGreatAxios]

critique · approve

Partial unique indexes, conflict-safe inserts, and 0025 keep-oldest repoint hold. walking-skeleton ran the DB-gated proofs green on main after #427.

• packages/chat/src/migrations.ts:462-468 — root/reply unique keys
• packages/chat/src/threads.ts:431-438 / 537-547 — onConflictDoNothing then re-select
• File-for-later: createDeliveryThread is still select-then-insert (out of CL-7130)

GitHub will not accept approve on the author's own PR; this comment is the review.