Add batch reads, @file completion, interruptible commands, tool sets

Tools, six built-in to fourteen:
- read_many_files: up to 20 paths read concurrently, each with its own window.
  An unreadable path is reported in its own block instead of throwing.
- multi_edit: several edits to one file, validated in memory first so a late
  failure cannot leave the file half-written.
- list_dir: ignore-aware depth-limited tree.
- git_status/diff/log/show/blame: read-only, spawned with a fixed argv rather
  than a shell string, which is what makes them safe to auto-approve.

toolSets gates them. core is always on; edit-plus and git are optional. A
disabled set reaches neither the wire nor the system prompt, since a prompt
naming an absent tool teaches calls that cannot succeed.

Interface:
- Reasoning streams to a collapsed panel, ctrl-r expands, dropped when the turn
  ends: it is progress, not the answer.
- The tool in flight is named from tool-input-start, before its arguments finish
  streaming, and cleared on its result.
- Prompts typed mid-turn queue and drain in order. esc clears the queue as well
  as aborting.
- @ opens a path picker fed by the ignore-aware walker. Prefix matches rank
  above substring matches, so @src/ means "under src/". The walk runs on the
  first @, not at startup.

ctrl-c kills the command in flight and keeps the turn. The call throws rather
than returning, so the model cannot read a killed command as one that ran and
failed on its own terms. The kill takes the whole process tree: killing cmd /c
alone left the real command holding both pipes open, so the read never returned
and the interrupt did nothing for 19 seconds.

Two pruning fixes:
- A tool result whose tool call was pruned is now dropped with it. Pruning
  counts messages, so the cut landed between an assistant tool-call and the tool
  message answering it, producing 400 "No tool call found for function call
  output with call_id ...". The reverse pairing is left alone: a call awaiting
  its result is what a suspended approval looks like.
- ignore.ts called statFs without importing it, so walk() crashed on the first
  symlink.

482 tests, up from 404. Docs synced across README, ROADMAP, TODO, and all of
docs/: tool sets, the new tools, ctrl-c semantics, the tool-start event, and the
two hand-maintained tool-name lists recorded as a known weakness.

src/prune.ts

@@ -1,6 +1,10 @@
 import { pruneMessages, type ModelMessage } from 'ai';
 
-type Part = { type: string; providerOptions?: Record<string, Record<string, unknown>> };
+type Part = {
+  type: string;
+  toolCallId?: string;
+  providerOptions?: Record<string, Record<string, unknown>>;
+};
 
 /** Parts the OpenAI responses API refuses to accept without their reasoning item. */
 const DEPENDENT = new Set(['text', 'tool-call']);
@@ -79,8 +83,54 @@ export function dropOrphanedItems(before: ModelMessage[], after: ModelMessage[])
 
 export type PruneOptions = Parameters<typeof pruneMessages>[0];
 
+const ANSWER_PARTS = new Set(['tool-result', 'tool-error']);
+
+const anyParts = (message: ModelMessage): Part[] =>
+  Array.isArray(message.content) ? (message.content as Part[]) : [];
+
+/**
+ * Drops tool results whose tool call is gone.
+ *
+ * The OpenAI responses API rejects a `function_call_output` with no `function_call`
+ * carrying the same call id: 400 "No tool call found for function call output with
+ * call_id ...". Two things strand a result that way, and both happen on a long turn:
+ * `pruneMessages({ toolCalls: 'before-last-3-messages' })` counts messages, so the
+ * cut can land between an assistant tool-call and the tool message answering it, and
+ * `dropOrphanedItems` removes a tool-call whose reasoning item did not survive while
+ * the result sits in a separate message it never looks at.
+ *
+ * The reverse pairing is left alone on purpose: a call still awaiting its result is
+ * exactly what a suspended approval looks like, and dropping it would break resume.
+ */
+export function dropOrphanedResults(messages: ModelMessage[]): ModelMessage[] {
+  const calls = new Set<string>();
+  for (const message of messages) {
+    for (const part of anyParts(message)) {
+      if (part.type === 'tool-call' && part.toolCallId) calls.add(part.toolCallId);
+    }
+  }
+
+  const cleaned: ModelMessage[] = [];
+  for (const message of messages) {
+    const parts = anyParts(message);
+    if (parts.length === 0) {
+      cleaned.push(message);
+      continue;
+    }
+
+    const kept = parts.filter(
+      (part) => !ANSWER_PARTS.has(part.type) || part.toolCallId === undefined || calls.has(part.toolCallId),
+    );
+
+    if (kept.length === parts.length) cleaned.push(message);
+    else if (kept.length > 0) cleaned.push({ ...message, content: kept } as ModelMessage);
+  }
+
+  return cleaned;
+}
+
 /** pruneMessages, then repair the provider-item dependencies it breaks. */
 export function prunePreservingItems(options: PruneOptions): ModelMessage[] {
   const pruned = pruneMessages(options);
-  return dropOrphanedItems(options.messages, pruned);
+  return dropOrphanedResults(dropOrphanedItems(options.messages, pruned));
 }