fix(v2): register tools with AI-SDK shape + idempotent system prompt

[ranxianglei]

What

Ports the two real V2 bug fixes from #8 (by @rorshopping) into the existing dual-shape entry — instead of merging #8's separate packages/v2/ second package, which contradicts AGENTS.md §2.3 (single dual-shape package is load-bearing). Supersedes #4 and #8.

The bugs (both confirmed present on master)

1. V2 tool registration shape — setupV2 did tools.add({ ...makeCompressTool(runtime), options }), spreading the V1 ToolDef { description, args(zod), execute(args, ToolContext) }. opencode V2's tools.add() needs the AI-SDK shape { name, description, input(JSON Schema), execute(input, ctx) → { content } }. So under V2 the four bili_* tools had no name, a zod object instead of a JSON Schema, and an unmapped execute ctx (V1 ToolContext requires directory/worktree, which V2 doesn't provide). The V2 tools were effectively non-functional.
2. Non-idempotent system prompt — SYSTEM_MARKER = "BILI CONTEXT MANAGEMENT" but SYSTEM_PROMPT begins with ACP TOOLS (billion-context) (packages/core/src/system-prompt.ts:14). findIndex always returned -1, so a duplicate system prompt was appended on every dispatch.

The fix

• new src/v2-tools.ts — toV2Tool(name, tool) wraps a V1 ToolDef into V2 shape. The input JSON Schema is derived via z.toJSONSchema(z.object(tool.args)) (zod 4.4.3, already bundled) — so the V2 schema cannot drift from the V1 definitions (this is better than fix(v2): register tools with the opencode2 API shape #8's hand-written schemas, which can). execute maps the V2 ctx onto the V1 ToolContext (callID ← ctx.id, empty directory/worktree) and unwraps the V1 result into { content }.
• src/index.ts — SYSTEM_MARKER corrected to "ACP TOOLS (billion-context)" and exported; setupV2's tools.add block uses the four V2 wrappers. The V1 path and the dual-shape export are untouched.
• new tests/v2-tools.test.ts — 4 regression tests: tool shape, schema projection (compress content[].{startId,endId,summary}, required:["content"]), execute ctx mapping + { content } unwrap, and SYSTEM_PROMPT.includes(SYSTEM_MARKER).

Why not merge #8 as-is

#8 implements these fixes in a second package packages/v2/ (billion-context-opencode-v2). AGENTS.md §2.3 is explicit: the project deliberately ships one package whose default export is Object.assign(biliAcpPluginV1, { id, setup }) — callable for V1 and carrying { id, setup } for V2. "Do not refactor the dual-shape export into two separate entries." master removed packages/v2/ specifically to adopt dual-shape, which is also why #8 is DIRTY (its base predates the removal). The correct home for these fixes is the existing setupV2.

Verification

Check	Result
npm run typecheck (both workspaces)	✅
npm test	✅ 54/54 (50 → 54)
npm run build	✅ dist/index.js 677.51 KB (zero new runtime deps; z.toJSONSchema is in the already-bundled zod)
node smoke.mjs	✅ ALL SMOKE TESTS PASSED
scripts/ci/check-pr.sh	✅ all checks passed

Scope / follow-ups

• Touches only the V2 adapter path + one test file. V1, @bili/core, the dual-shape export, and the bundle's dependency surface are unchanged.
• After merge, Add OpenCode V2 adapter (v2/) on acp-kernel #4 and fix(v2): register tools with the opencode2 API shape #8 can be closed (their fixes are incorporated into the canonical package).
• Known limitation (same as fix(v2): register tools with the opencode2 API shape #8): the V2 tool shape is unit-tested but not exercised against a live opencode2 runtime in CI.
• Separate (out of scope): the kernel hardcodes the generic tool name 'compress' in its call↔result pairing rules, leaking consumed bili_compress invocations — needs a kernel-side fix.