v1.13.1-C: port ask_user_input correlation to parts + wire reasoning_parts end-to-end

Pass 1 — ask_user_input correlation port (messages.ts:478, :549):

- The two correlation queries that backed the elicitation flow used to scan
  messages.tool_calls and messages.tool_results JSON columns directly. They
  now JOIN message_parts on payload->>'id' (for the caller assistant) and
  payload->>'tool_call_id' (for the pending tool row). Semantics preserved:
  ORDER BY m.created_at DESC LIMIT 1 still picks the latest issuance, the
  already-answered 409 guard now reads payload.output, and the UPDATE +
  parts replace inside sql.begin is unchanged from v1.13.0.
- Pre-v1.13.0 history has no parts rows and is unreachable to this lookup
  path (404). Acceptable per dispatch decision — no pending elicitation
  from before v1.13.0 will still be open. JSON-column fallback can land as
  a hotfix if it ever surfaces.

Pass 2 — reasoning_parts wired end-to-end:

- types.ts/StreamResult gains `reasoning: string`. stream-phase.ts accumulates
  reasoning-delta text per stream (replacing the v1.13.1-A counter-only
  diagnostic) and returns it on the result.
- parts.ts/partsFromAssistantMessage gains an optional `reasoning` param.
  When present it emits a kind='reasoning' part at sequence 0, ahead of
  the text and tool_call parts.
- error-handler.ts/finalizeCompletion and tool-phase.ts/executeToolPhase
  both thread result.reasoning into the dual-write call so reasoning-channel
  models (qwen3.6) get persistent reasoning rows.
- payload.ts: loadContext SELECT pulls reasoning_parts from the v1.13.1-B
  view; OpenAiMessage gains an optional `reasoning` field; buildMessagesPayload
  collapses reasoning_parts into a single string per assistant message.
- stream-phase.ts/toModelMessages converts assistant messages with reasoning
  into an AI SDK ModelMessage content array starting with a ReasoningPart,
  matching the @ai-sdk/provider-utils AssistantContent union. Reasoning
  models can now replay prior reasoning context across tool-call boundaries.
- types/api.ts and apps/web/src/api/types.ts Message interface gain
  reasoning_parts (optional, nullable). Frontend doesn't render this yet —
  field reserved for a v1.14 UI surface.

Tests: 2 new in parts.test.ts cover reasoning-at-sequence-0 with and
without text content. 172 tests pass (170 prior + 2 new).

Smoke verified against the live container:
- A reasoning-prompt ("walk through 17 × 23 step by step") produced one
  message with kind='reasoning' (361 chars) at sequence 0 and kind='text'
  (429 chars) at sequence 1. Adapter log confirmed reasoning capture.
- The new correlation SQL was validated against existing tool_call /
  tool_result parts: returns the expected message_id + payload shape with
  pending state correctly identified via payload.output IS NULL.
- ask_user_input end-to-end through the UI is Sam's smoke — the Prompt
  Builder agent does not always trigger ask_user_input for these prompts,
  so synthetic verification via SQL substituted for traffic-driven cover.

Annotation: the v1.13.1-A abort-throw site in stream-phase.ts got a
one-liner comment ("AI SDK v6 fullStream returns normally on abort; check
signal explicitly.") to prevent a future refactor removing it.

v1.13.2 drops the dual-write + the JSON columns + collapses the view.

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

apps/server/src/routes/messages.ts

@@ -470,30 +470,36 @@ export function registerMessageRoutes(
       const chat = chatRows[0]!;
       const sessionId = chat.session_id;
 
-      // Find the assistant message that emitted this tool_call. Scoped by
-      // chat_id + role to avoid cross-chat lookups; ordered by created_at DESC
-      // because the most recent issuance wins when an LLM reuses call IDs
-      // across turns (the older, already-answered one is a different row with
-      // populated tool_results downstream).
-      const callerRows = await sql<{ id: string; tool_calls: ToolCall[] | null }[]>`
-        SELECT id, tool_calls FROM messages
-        WHERE chat_id = ${chat.id}
-          AND role = 'assistant'
-          AND tool_calls IS NOT NULL
-        ORDER BY created_at DESC
+      // v1.13.1-C: find the assistant's tool_call by indexing message_parts
+      // directly on payload->>'id'. Scoped by chat_id + role via the JOIN.
+      // Pre-v1.13.0 history has no parts rows — those tool_calls become
+      // unreachable here (404). Acceptable per the dispatch decision: any
+      // pending elicitation from before v1.13.0 is long timed out by now;
+      // promote to a hotfix with a JSON-column fallback if it ever surfaces.
+      const callerRows = await sql<{
+        message_id: string;
+        payload: { id: string; name: string; args: Record<string, unknown> };
+      }[]>`
+        SELECT p.message_id, p.payload
+        FROM message_parts p
+        JOIN messages m ON m.id = p.message_id
+        WHERE m.chat_id = ${chat.id}
+          AND m.role = 'assistant'
+          AND p.kind = 'tool_call'
+          AND p.payload->>'id' = ${tool_call_id}
+        ORDER BY m.created_at DESC
+        LIMIT 1
       `;
-      let foundCall: ToolCall | null = null;
-      for (const row of callerRows) {
-        const match = row.tool_calls?.find((tc) => tc.id === tool_call_id);
-        if (match) {
-          foundCall = match;
-          break;
-        }
-      }
-      if (!foundCall) {
+      const callerRow = callerRows[0];
+      if (!callerRow) {
         reply.code(404);
         return { error: 'unknown_tool_call_id' };
       }
+      const foundCall: ToolCall = {
+        id: callerRow.payload.id,
+        name: callerRow.payload.name,
+        args: callerRow.payload.args,
+      };
       if (foundCall.name !== 'ask_user_input') {
         reply.code(400);
         return { error: 'tool_call_not_ask_user_input' };
@@ -540,18 +546,21 @@ export function registerMessageRoutes(
         }
       }
 
-      // Find the pending tool row. ORDER BY created_at DESC + LIMIT 1 picks
-      // the most recent row with this tool_call_id; the already-answered
-      // check below guards against UPDATE-ing a stale answer.
+      // v1.13.1-C: find the pending tool row via message_parts on
+      // payload->>'tool_call_id'. Same fallback caveat as the caller lookup
+      // above — pre-v1.13.0 rows are unreachable here.
       const toolRows = await sql<{
-        id: string;
-        tool_results: { tool_call_id: string; output: unknown } | null;
+        message_id: string;
+        payload: { tool_call_id: string; output: unknown };
       }[]>`
-        SELECT id, tool_results FROM messages
-        WHERE chat_id = ${chat.id}
-          AND role = 'tool'
-          AND tool_results->>'tool_call_id' = ${tool_call_id}
-        ORDER BY created_at DESC
+        SELECT p.message_id, p.payload
+        FROM message_parts p
+        JOIN messages m ON m.id = p.message_id
+        WHERE m.chat_id = ${chat.id}
+          AND m.role = 'tool'
+          AND p.kind = 'tool_result'
+          AND p.payload->>'tool_call_id' = ${tool_call_id}
+        ORDER BY m.created_at DESC
         LIMIT 1
       `;
       const toolRow = toolRows[0];
@@ -559,7 +568,7 @@ export function registerMessageRoutes(
         reply.code(404);
         return { error: 'unknown_tool_call_id', detail: 'tool message not found' };
       }
-      if (toolRow.tool_results && toolRow.tool_results.output !== null) {
+      if (toolRow.payload && toolRow.payload.output !== null) {
         reply.code(409);
         return { error: 'tool_call_already_answered' };
       }
@@ -571,20 +580,21 @@ export function registerMessageRoutes(
         truncated: false,
       };
 
+      const toolMessageId = toolRow.message_id;
       const result = await sql.begin(async (tx) => {
         await tx`
           UPDATE messages
           SET tool_results = ${tx.json(newToolResults as never)}
-          WHERE id = ${toolRow.id}
+          WHERE id = ${toolMessageId}
         `;
         // v1.13.0: replace the pending tool_result part inserted at message
         // creation (tool-phase.ts) with the answered one. Delete-then-insert
         // is simpler than UPDATE because parts are append-style elsewhere;
         // the UNIQUE (message_id, sequence) constraint blocks plain insert.
-        await tx`DELETE FROM message_parts WHERE message_id = ${toolRow.id} AND kind = 'tool_result'`;
+        await tx`DELETE FROM message_parts WHERE message_id = ${toolMessageId} AND kind = 'tool_result'`;
         await tx`
           INSERT INTO message_parts (message_id, sequence, kind, payload)
-          VALUES (${toolRow.id}, 0, 'tool_result', ${tx.json(newToolResults as never)})
+          VALUES (${toolMessageId}, 0, 'tool_result', ${tx.json(newToolResults as never)})
         `;
         const [assistantMsg] = await tx<{ id: string }[]>`
           INSERT INTO messages (session_id, chat_id, role, content, status, created_at)
@@ -594,7 +604,7 @@ export function registerMessageRoutes(
         await tx`UPDATE sessions SET updated_at = clock_timestamp() WHERE id = ${sessionId}`;
         await tx`UPDATE chats SET updated_at = clock_timestamp() WHERE id = ${chat.id}`;
         return {
-          tool_message_id: toolRow.id,
+          tool_message_id: toolMessageId,
           assistant_message_id: assistantMsg!.id,
         };
       });