fix(acp): accept concurrent prompts while session is busy

[shuxueshuxue]

Problem

The ACP client can send a second session/prompt while a tool is running. In v0.1.13, packages/opencode/src/server/routes/instance/session.ts rejects the request with SessionRunState.assertNotBusy (HTTP 409). The ACP SDK caller does not surface that 409 as an error, so the prompt becomes a silent no-op.

The opencode v1.18.16 handler accepts the prompt and delegates to promptSvc.prompt; its Runner.ensureRunning preserves ordering and merges the new user message into the active runner.

Fix

Remove only the /message route pre-check. Keep Runner.ensureRunning unchanged so concurrent prompts are serialized by the existing runner and are available to the next tool boundary.

Evidence

Using an isolated ACP probe with a deterministic OpenAI-compatible SSE endpoint and four sequential bash tool calls:

• Before patch: four-tool run plus cross-turn follow-up dropped the marker from every model request.
• After patch: marker appears in request 4 (after the second tool) and remains visible in request 7 after end_turn (B/B').
• Concurrent marker control: sending MARKER_A_1 and MARKER_B_2 together produced both markers in request 4+, ordered A-before-B. Sending only A produced A=true/B=false, proving the detector.

A prior attempt to transplant opencode runUntilIdle was insufficient: it delayed ACP response completion but could not recover a prompt already rejected by this route gate.

The ACP client should also surface HTTP 409 responses instead of resolving them as an empty success; that is tracked separately in downstream issue #4489.