fix(ai-providers): read the system prompt and tools from the Pi 0.86+ transcript

[JS-banana]

Problem

Closes #619.

Pi 0.86.0 changed a custom provider's stream input from Context to a normalized TranscriptContext: the system prompt and tool declarations are folded into a leading transcript system message, and later system messages carry prompt/tool deltas. The Antigravity adapter still read context.systemPrompt / context.tools, so that leading system message fell through to the tool-result branch and became a functionResponse with no name:

GenerateContentRequest.contents[0].parts[0].function_response.name: Name cannot be empty.

Every request on Pi 0.86+ failed, and independently of the 400 the system prompt and all tool declarations were dropped. Cursor read the same two fields and silently fell back to its generic chat-only prompt with no tools.

Value

google-antigravity works again on Pi 0.86+ while the declared Pi 0.85.1 baseline keeps working unchanged, and the failure class is closed at the shared cause rather than per provider.

Approach

• New extensions/ai-providers/transcript.ts: replays transcript system messages into the prompt and tool set currently in effect, mirroring Pi's getCurrentSystemPrompt / getCurrentTools without importing helpers that do not exist before Pi 0.86. applyTranscript returns the old Context untouched, so Pi <= 0.85.1 behavior is preserved exactly.
• Antigravity buildRequestBody resolves the transcript once; convertMessages receives conversation messages only; buildTools takes the resolved tool list.
• Google converter: only assistant turns are rewritten, and non-conversation roles or nameless tool results no longer become a functionResponse.
• Cursor: buildCursorRequest / streamCursor resolve the transcript at the entry point.
• No dependency, lockfile, or peer-range change — this lands independently of the baseline discussion in chore(deps): define and enforce the supported Pi baseline #328.

Validation

• Differential against Pi 0.87.1's own replay (getCurrentSystemPrompt / getCurrentTools) across five message sets — leading system message; later section patch with toolsRemoved / toolsAdded; content plus sections; two system messages; no system message. Prompt text and tool set are identical in all five.
• tests/extensions/ai-providers/antigravity.test.ts 58/58 and cursor.test.ts 35/35. The four new regression tests fail when the provider changes are stashed, so they pin the regression rather than the implementation.
• Real account on Pi 0.87.1, extension loaded with -ne -ns -np -nc --no-session -e extensions/ai-providers/index.ts:
  • control (unpatched npm @tt-a1i/openpi@0.8.1): the exact 400 from bug(antigravity): Pi 0.86+ 下 provider stream 收到 TranscriptContext，每次请求都以 400 失败 #619;
  • patched: gemini-3.8-flash-high plain reply, read tool round trip, and claude-sonnet-4-6 read tool round trip.
• node --test: 1888 passed / 0 failed / 5 skipped. bun run lint, format:check, check:config-contract, check:docs-contract, check:discipline pass. tsc --noEmit reports 20 errors, identical to the baseline on this checkout (missing node-pty / @xterm/*): 0 new.

Impact

• Fixes the antigravity 400 and restores prompt/tool delivery on Pi 0.86+; no wire-format change for Pi <= 0.85.1.
• Touches extensions/ai-providers/antigravity/google-conversion.ts, which fix(antigravity): preserve local schema refs #488 also modifies; this branch is based on 43cd2e9 and does not include fix(antigravity): preserve local schema refs #488.
• Not verified: a real Cursor turn (chat-only, needs a Cursor login); the cursor change is covered by unit tests only.
• Does not move the peer range or lockfile. Whether the supported baseline should become >= 0.86 stays with chore(deps): define and enforce the supported Pi baseline #328.

[JS-banana]

CI note: Background terminals (Windows) failed on streamAntigravity bounds the full SSE lifetime after the first event.

That test is pre-existing and sets timeoutMs: 5, so the first SSE read has a 5 ms budget; on the Windows runner it lost that race and reported the first-event timeout (Timed out waiting for the first SSE event) instead of the lifetime timeout (next SSE event). It passed on Node 22.19.0 / 24 / 26 and in Web E2E in this same run, and this branch does not touch the SSE timing or failover path.

The Windows job is currently failing on other branches for unrelated tests — docs-only #618 failed it on not ok 215, and feat/session-child-admission failed it on not ok 804 — so this reads as the existing Windows flake rather than a regression from this change. I cannot re-run the job myself (no admin rights on this repository); a re-run should clear it.