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/tool-phase.ts

@@ -3,6 +3,7 @@ import * as modelContext from '../model-context.js';
 import { PathScopeError } from '../path_guard.js';
 import { TOOLS_BY_NAME } from '../tools.js';
 import { maybeFlagForCompaction } from './payload.js';
+import { insertParts, partsFromAssistantMessage, partsFromToolMessage } from './parts.js';
 import type {
   InferenceContext,
   StreamResult,
@@ -97,6 +98,20 @@ export async function executeToolPhase(
     WHERE id = ${assistantMessageId}
     RETURNING tokens_used, ctx_used, ctx_max, finished_at
   `;
+  // v1.13.0: dual-write to message_parts. Reads still consume the JSON
+  // columns above; this mirrors the same data into the granular table so
+  // the AI SDK migration can swap reads later without a backfill window.
+  // TODO(v1.13.1): wrap the UPDATE above and this insertParts in a single
+  // sql.begin before flipping read authority to message_parts. Without the
+  // transaction, a crash between the two leaves an orphan message that
+  // becomes invisible in the parts-authoritative read path.
+  await insertParts(
+    ctx.sql,
+    partsFromAssistantMessage({ content, tool_calls: toolCalls }).map((p) => ({
+      ...p,
+      message_id: assistantMessageId,
+    })),
+  );
   // v1.11: flag for compaction if this turn pushed us over the usable budget.
   // We never compact mid-loop (the recursive runAssistantTurn keeps tools
   // flowing); the flag fires on the NEXT turn's pre-fetch hook above.
@@ -150,6 +165,18 @@ export async function executeToolPhase(
           SET tool_results = ${ctx.sql.json(sentinel as never)}
           WHERE id = ${toolMessageId}
         `;
+        // v1.13.0: mirror the pending sentinel into message_parts. The
+        // answer-endpoint UPDATE later (messages.ts:576) will delete and
+        // re-insert this part when the user submits their answer.
+        // TODO(v1.13.1): wrap the INSERT + UPDATE + insertParts triple in
+        // a per-iteration sql.begin before flipping read authority.
+        await insertParts(
+          ctx.sql,
+          partsFromToolMessage({ tool_results: sentinel }).map((p) => ({
+            ...p,
+            message_id: toolMessageId,
+          })),
+        );
         return;
       }
       const tres = await executeToolCall(projectRoot, tc);
@@ -164,6 +191,16 @@ export async function executeToolPhase(
         SET tool_results = ${ctx.sql.json(stored as never)}
         WHERE id = ${toolMessageId}
       `;
+      // v1.13.0: dual-write the tool_result part.
+      // TODO(v1.13.1): wrap the INSERT + UPDATE + insertParts triple in a
+      // per-iteration sql.begin before flipping read authority.
+      await insertParts(
+        ctx.sql,
+        partsFromToolMessage({ tool_results: stored }).map((p) => ({
+          ...p,
+          message_id: toolMessageId,
+        })),
+      );
       ctx.publish(sessionId, {
         type: 'tool_result',
         tool_message_id: toolMessageId,