feat(ai): Ask this session (core + Pi)

[backnotprop]

Phase 1 of "Ask this session" (build order steps 1-3 of .product/drafts/session-ask-ai/DESIGN.md): Ask AI answered by the agent session that opened Plannotator.

Core (packages/ai/session-bridge.ts, vendored to Pi)

• SessionBridge host interface (ready | busy | blocked | gone, turn/transient modes, ask, optional interrupt) and a session-bridge provider behind the existing /api/ai/* endpoints in both runtimes. It is registered last, so the server default does not change.
• One question at a time across threads. No system prompt; the question starts with a Plannotator header line.
• A busy session answers agent_busy. The client then re-asks with busyPolicy: "wait" or "interrupt" on /api/ai/query.
• Abort cancels only our question. The runtime detaches the bridge before teardown, so a decision or exit never stops a turn that is already running.

UI

• "Ask this session · Pi" with no model picker. It is the default when the bridge can answer; a saved explicit choice still wins.
• Busy shows "Ask when it finishes" / "Interrupt and ask now". Gone or blocked shows "Ask a separate AI instead", which switches this page only (the cookie is not written) and re-asks.
• Code review sends the diff's identity, not the patch.
• Hosts without a bridge get the same requests and DOM as before: no new fields and no new elements.

Pi

• pi-session-bridge.ts covers review, annotate and last. Each question is a real turn (sendMessage with customType: "plannotator-ask" and triggerTurn), streamed from the session's events.
• Off in remote mode.
• Pi plan review is unchanged (see below).
• Fix: the Pi server never cancelled the SSE stream when the client disconnected, so closing the tab or superseding a question left the turn running. The Bun server already handled this. Covered by a Node-run test.

Where Pi differed from the design

• pi.on returns void in the installed Pi 0.84/0.85; only 1.0 returns an unsubscribe. So the listeners are registered once at load and route events to the active question.
• pi.sendMessage returns void and reports async failures to Pi's own error channel. A watchdog fails a question that never reaches the session.
• "Interrupt and ask now" uses ctx.abort() and then asks. Pi's steer would also work, but it merges the question into the user's turn.

Verified live in Pi 0.85.1 (RPC mode, real model) for annotate, last and review:

• streamed answer, and the question is in the transcript;
• agent_busy, then wait, then the answer;
• interrupt, then the answer;
• Stop ends Pi's turn in about 100 ms;
• new_session gives session_gone.

A headless Chromium run of the annotate UI showed the label, no model picker, the busy choice, the waiting status and the answer.

Tests: typecheck, bun test, the CI DOM lists, build:pi and the guides.show manifest check all pass.

Not in this PR: Pi plan review. submit_plan awaits openPlanReviewBrowser inside a sequential tool, so the session is blocked until the decision. To make it non-blocking:

1. Return from the tool right away with a "plan under review" result.
2. Deliver the decision later as a follow-up message, as review/annotate already do.
3. Move the approve-side phase transitions (tools, model, thinking level, todo sync) from the tool result into that follow-up path.
4. Guard against the agent continuing to work while the plan is pending, for example by keeping planning-phase tool scoping until the decision arrives.
5. Pass the bridge to startPlanReviewServer (the Bun option already exists).