v1.13.0: message_parts table + dual-write at every tool_calls/tool_results site

Adds a granular message_parts table (one row per text/tool_call/tool_result
chunk) without changing any read path. Old messages.content / tool_calls /
tool_results columns remain authoritative for v1.13.0; this dispatch is
write-only mirroring so the AI SDK migration in v1.13.1 can flip read
authority without a backfill window.

Schema:
  CREATE TABLE message_parts (id, message_id FK ON DELETE CASCADE,
    sequence int, kind text CHECK (text|tool_call|tool_result|reasoning|step_start),
    payload jsonb, created_at, UNIQUE (message_id, sequence))

New module services/inference/parts.ts with two pure derive helpers
(partsFromAssistantMessage, partsFromToolMessage) and insertParts that
fan-outs a multi-row INSERT via postgres-js.

Wired dual-write at every site that writes tool_calls or tool_results:
- tool-phase.ts: assistant finalize UPDATE, executed-tool UPDATE,
  ask_user_input sentinel UPDATE
- messages.ts answer flow: DELETE pending tool_result part + INSERT
  answered one inside the existing sql.begin
- skills.ts: synthetic assistant + tool INSERTs both inside existing tx
- chats.ts fork: CTE clones parts via ROW_NUMBER pairing (source→dest
  message id mapping in one statement, no N+1)
- error-handler.ts finalizeCompletion: text part for plain text-only
  assistant turns

Deviation: tool-phase.ts finalize UPDATEs and finalizeCompletion text-part
write are not wrapped in fresh sql.begin transactions. Safe in v1.13.0
because JSON columns are authoritative for reads. v1.13.1 must wrap these
sites before flipping read authority — TODO comments added at each
unwrapped site referencing v1.13.1.

Tests: 8 new unit tests for the derive helpers in
services/__tests__/parts.test.ts. Existing 162 tests untouched. 170 total.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

apps/server/src/services/inference/error-handler.ts

@@ -1,6 +1,7 @@
 import type { MessageMetadata, Session } from '../../types/api.js';
 import * as modelContext from '../model-context.js';
 import { maybeFlagForCompaction } from './payload.js';
+import { insertParts, partsFromAssistantMessage } from './parts.js';
 import type { InferenceContext, StreamResult, TurnArgs } from './turn.js';
 
 export async function handleAbortOrError(
@@ -112,6 +113,18 @@ export async function finalizeCompletion(
     WHERE id = ${assistantMessageId}
     RETURNING tokens_used, ctx_used, ctx_max, finished_at
   `;
+  // v1.13.0: dual-write the text part. finalizeCompletion is the terminal
+  // path for text-only assistant turns (no tool calls); tool_calls are null
+  // here by construction (the tool-bearing path goes through executeToolPhase).
+  // TODO(v1.13.1): wrap the UPDATE above and this insertParts in a single
+  // sql.begin before flipping read authority to message_parts.
+  await insertParts(
+    ctx.sql,
+    partsFromAssistantMessage({ content, tool_calls: null }).map((p) => ({
+      ...p,
+      message_id: assistantMessageId,
+    })),
+  );
   // v1.11: flag for compaction on the terminal turn too. Catches the common
   // case of a turn that hit the limit without invoking tools.
   await maybeFlagForCompaction(ctx, chatId, updated);