…timing and extension dispatch

Resolves #1339.

Lifecycle hook context types are now derived from the AI SDK so users get
full typed access instead of `unknown`:

- `StepContext<TOOLS>` = `StepResult<TOOLS>` — `reasoning`, `sources`,
  `files`, `providerMetadata` (cache tokens), `request`/`response`,
  `warnings`, full `LanguageModelUsage` (incl. `cachedInputTokens`,
  `reasoningTokens`).
- `ChunkContext<TOOLS>` = AI SDK's `StreamTextOnChunkCallback` event
  (discriminated `TextStreamPart`).
- `ToolCallContext<TOOLS>` spreads `TypedToolCall<TOOLS>` plus
  `stepNumber`, `messages`, `abortSignal`.
- `ToolCallResultContext<TOOLS>` spreads `TypedToolCall<TOOLS>` plus
  `durationMs`, `messages`, `stepNumber`, and a discriminated
  `success`/`output`/`error` outcome.

The relevant AI SDK types (`StepResult`, `TextStreamPart`,
`TypedToolCall`, `TypedToolResult`) are re-exported from the package.

Tool-call hook timing is now correct: `beforeToolCall` fires before
`execute` (Think wraps every tool's `execute`), and `afterToolCall` fires
after via `experimental_onToolCallFinish` with accurate `durationMs`.
Previously both fired post-execution from `onStepFinish` data, and the
wrapper was reading `tc.args` / `tr.result` (the AI SDK uses `input` /
`output`) so subclass hooks always saw `{}` and `undefined`.

`ToolCallDecision` is now functional. Returning `{ action: "block",
reason }`, `{ action: "substitute", output }`, or `{ action: "allow",
input }` from `beforeToolCall` actually intercepts execution.

Extension dispatch for `beforeToolCall` / `afterToolCall` /
`onStepFinish` / `onChunk`. The `ExtensionManifest.hooks` array claimed
support for these but Think only ever dispatched `beforeTurn`. All five
hooks now dispatch with JSON-safe snapshots. Extension hook handlers
also receive `(snapshot, host)` symmetric with tool `execute`;
previously only tool executes got the host bridge.

Test mocks updated to the AI SDK v3 LanguageModel spec
(`finishReason: { unified, raw }`, structured `usage` with
`{ inputTokens: { total, ... }, outputTokens: { total, text, reasoning } }`,
explicit `tool-call` chunks). The previous mocks were quietly relying on
fallbacks in the wrapper that masked these shape mismatches.

Breaking renames per AI SDK conventions: `ToolCallContext.args` ->
`input`, `ToolCallResultContext.args` -> `input`,
`ToolCallResultContext.result` -> `output`. `afterToolCall` is now a
discriminated union — read `output` only when `ctx.success === true`,
and `error` when `ctx.success === false`. Equivalent renames on
`ToolCallDecision`.

247/247 tests passing. Docs and the assistant example are updated.

Made-with: Cursor

`waitForIdle` and `waitUntilStable` previously only awaited
`_turnQueue.waitForIdle()`. They missed submits that had passed
`_getSubmitConcurrencyDecision` (so already bumped
`_latestOverlappingSubmitSequence` and incremented
`_pendingEnqueueCount`) but hadn't yet reached `_runExclusiveChatTurn`
because they were mid-`persistMessages`. Anything calling these helpers
(tests, recovery code, callers waiting for quiescence) could race the
in-flight submit and observe the agent as "idle" when it really wasn't.

Both helpers now poll on `_pendingEnqueueCount === 0` after the queue
drains, with a brief setTimeout yield between checks so in-flight
handlers can reach the enqueue call.

Fixes the long-standing flake in
`merge concatenates overlapping queued user messages into one follow-up
turn`. Also bumps that test's stream durations (10×100ms → 15×150ms) to
give the WS dispatch enough headroom under CI load to bump
`_latestOverlappingSubmitSequence` *before* the first turn finishes —
the supersession check on the second submit needs to see the latest
counter value, and `waitForOverlappingSubmits` only helps if the third
submit's handler has actually run.

Made-with: Cursor

…nwrapped

`_wrapToolsWithDecision` previously did:

    const result = originalExecute(finalInput, options);
    if (Symbol.asyncIterator in (result as object)) { ...collapse... }

For an `async function execute(...) { return makeAsyncIterable(); }`
(the common shape if you build the iterator inside the async body),
`originalExecute(...)` returns `Promise<AsyncIterable>` — and
`Symbol.asyncIterator in Promise` is always false. The collapse logic
was skipped. The wrapper is async, so it auto-unwrapped one Promise
layer and effectively returned `Promise<AsyncIterable>`. The AI SDK's
`executeTool` then `await`s that, gets the AsyncIterable, and yields
`{ type: "final", output: AsyncIterable }` — exactly the broken case
the wrapper's own comment warned against.

Fix: await `originalExecute(finalInput, options)` before inspecting,
so the symbol check sees the resolved value (an AsyncIterable in any
of: direct return, `async function*`, or `async () => makeIter()`).

Verified by adding two regression tests:

- `collapses Promise<AsyncIterable> returns to the last yielded value`
  (the buggy case — fails on the pre-fix code with the iterator
  serializing to `{}`)
- `collapses sync AsyncIterable returns to the last yielded value`
  (the case that already worked — belt-and-suspenders)

Updated docs and JSDoc to spell out that all three iterator-return
shapes are handled identically.

Spotted by code review on #1340.

Made-with: Cursor