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/parts.ts

@@ -0,0 +1,86 @@
+import type { Sql } from '../../db.js';
+import type { ToolCall, ToolResult } from '../../types/api.js';
+
+// v1.13.0: dual-write helper. Every site that writes the legacy
+// messages.tool_calls / messages.tool_results JSON columns calls into here
+// to mirror the same data into message_parts rows. Reads still go to the
+// JSON columns; the swap to parts-as-source-of-truth happens in a later
+// v1.13 dispatch alongside the AI SDK streamText migration.
+
+export type PartKind = 'text' | 'tool_call' | 'tool_result' | 'reasoning' | 'step_start';
+
+export interface PartInsert {
+  message_id: string;
+  sequence: number;
+  kind: PartKind;
+  payload: unknown;
+}
+
+export async function insertParts(sql: Sql, parts: PartInsert[]): Promise<void> {
+  if (parts.length === 0) return;
+  // postgres-js fans out an array of objects to a multi-row INSERT. Each
+  // payload field needs sql.json() so jsonb storage receives a JSON value
+  // rather than a quoted string.
+  await sql`
+    INSERT INTO message_parts ${sql(
+      parts.map((p) => ({
+        message_id: p.message_id,
+        sequence: p.sequence,
+        kind: p.kind,
+        payload: sql.json(p.payload as never),
+      })),
+      'message_id',
+      'sequence',
+      'kind',
+      'payload',
+    )}
+  `;
+}
+
+// Derive parts from the canonical messages row for an assistant message.
+// content (when non-empty) becomes a 'text' part at sequence 0; each tool_call
+// becomes a 'tool_call' part with payload { id, name, args } where args is
+// the parsed object (we use the in-memory ToolCall shape, not the OpenAI
+// stringified one).
+export function partsFromAssistantMessage(args: {
+  content: string;
+  tool_calls: ToolCall[] | null;
+}): Omit<PartInsert, 'message_id'>[] {
+  const out: Omit<PartInsert, 'message_id'>[] = [];
+  let seq = 0;
+  if (args.content && args.content.length > 0) {
+    out.push({ sequence: seq, kind: 'text', payload: { text: args.content } });
+    seq += 1;
+  }
+  for (const tc of args.tool_calls ?? []) {
+    out.push({
+      sequence: seq,
+      kind: 'tool_call',
+      payload: { id: tc.id, name: tc.name, args: tc.args },
+    });
+    seq += 1;
+  }
+  return out;
+}
+
+// Derive a single tool_result part from a tool message's tool_results JSON.
+// The payload includes the same shape that buildMessagesPayload reads from
+// later: tool_call_id, output, optional error/truncated metadata.
+export function partsFromToolMessage(args: {
+  tool_results: ToolResult | null;
+}): Omit<PartInsert, 'message_id'>[] {
+  if (!args.tool_results) return [];
+  const tr = args.tool_results;
+  return [
+    {
+      sequence: 0,
+      kind: 'tool_result',
+      payload: {
+        tool_call_id: tr.tool_call_id,
+        output: tr.output,
+        truncated: tr.truncated,
+        ...(tr.error ? { error: tr.error } : {}),
+      },
+    },
+  ];
+}