fix(chat): settle a turn once, so an abort is not a completion

[mrsibe]

Step 1 of the chat execution epic (#138), closing #139. It fixes the last two ways a turn was reported as something it wasn't, and puts the decision in one place so the next event type cannot invent a third.

What was still wrong after #137

#137 made an in-stream error part fail the turn instead of completing it. Two siblings of that bug were left:

A user abort was a completion. ModelClient's catch called onComplete() whenever the signal was aborted, so chatHandlers persisted the partial text as a finished turn. Whether the renderer also received the terminal finish chunk depended on whether the SDK's delayed usage / finishReason promises rejected — the same user action could land in either state.

An EOF was a completion. Falling out of for await was treated as success. The AI SDK's contract says the opposite — "Only errors that stop the stream, such as network errors, are thrown" — so an iterator that ends normally carries no claim about the answer. await result.finishReason would have hidden this: it synthesises 'unknown' when no terminal part arrived.

What this changes

type ChatExecutionStatus = 'pending' | 'streaming'
                         | 'completed' | 'truncated' | 'blocked' | 'aborted' | 'failed'

status is KnowNote's statement; finishReason stays the provider's fact, and they are stored as two fields precisely because they are not the same statement:

stop · tool-calls      → completed
length                 → truncated      the answer is kept and explained, not failed
content-filter         → blocked
an error part / throw  → failed (error)
no terminal signal     → failed (unexpected_eof)
user abort             → aborted

• One decision, taken once. shared/utils/chatExecution.ts holds the mapping plus settleOutcome, the first-terminal-wins rule. A stream can deliver several terminal-looking events — the SDK keeps delivering text after an error part, and transport cleanup can throw after a legitimate finish — and promoting one of them re-labels an answer the reader already has.
• ModelClient reports, it does not decide. An abort is its own callback, onError carries whether the provider reported the failure or the stream broke, and the reason comes from the SDK's finish part instead of the aggregate promise. The four positional callbacks became an object: with onError / onAbort / onComplete all meaning "the turn ended, differently", a positional call site is one reordering away from this exact bug.
• The outcome is stored. chat_messages gains status, finish_reason, error, usage, finished_at — migration 0017, additive. A row written earlier reads back status = NULL, which means unknown; the same distinction parseRetrievalStatus already makes, and deliberately not completed.
• Persist first, announce second. The terminal event now goes out after the write returns, so a failed write cannot leave the transcript claiming a turn the database does not have.

createMessage gained an optional status, and the assistant row is now created as streaming — the row is the turn record.

Scope

Per the epic's split, this is only the semantics and the storage. Not here: ChatStreamManager (#140), the chunk-stream protocol and the deletion of the hand-made done chunk (#141), and everything the transcript renders from status (#142). One consequence worth stating: aborted is persisted but not announced, because the renderer cleared its streaming state when it asked for the stop — announcing it would be a second state change nobody requested. The reload path is #142's job.

Two behaviour changes worth naming:

• a failed turn keeps its partial content, so a reload shows the partial answer plus its failure where it used to show an empty message;
• a turn that failed is now counted into the session token estimate rather than skipped (an aborted turn already was, through onComplete).

Verification

npm test	297 pass, 0 fail — 9 new: test/chatExecution.test.ts (7) pins the mapping, the missing-terminal case, and first-terminal-wins in both orders; test/chatStreamOutcome.test.ts gained the abort case and a test that pins the SDK's synthesised finish part, which is what makes "no terminal part at all" a fact rather than an assumption
npm run typecheck	clean (node, web, test)
npm run check:design	no violations
npm run build:unpack + npm run smoke:packaged	PASS — 23 checks, one new: a terminal outcome round-trips through the packaged database (JSON + timestamp columns, partial content kept)
migration 0017 on a real database	applied by hand to a copy of an existing pre-migration DB: the five ALTERs are additive, and a legacy row keeps status = NULL
npx eslint <changed files>	0 errors; the 3 no-explicit-any warnings are pre-existing lines

The stream tests drive ModelClient with a scripted provider from ai/test, including an abortable stream that errors on the signal the way a real transport does — a fake that ignored the signal would leave the SDK's iterator open forever, which is a property of that fake rather than of the code.

Not verified by hand: the transcript's rendering of a stopped or failed turn. The states exist and are stored; showing them is #142. GUI confirmation is part of #125's pass.

Next

#140 (ChatStreamManager) is the next step and is what turns this fixed vocabulary into a real lifecycle owner — abort recording, subscriber bookkeeping, and a bounded buffer for opening a notebook mid-turn.