fix(web): report queued prompt position

[testikun]

Problem

Related to #363. Existing Web prompt admission reports only that a prompt was accepted. During a long active turn, a follow-up can be queued, but the browser has no canonical queue-position evidence and must guess from local state. This complements PR #364's running-state fix, PR #377's request timeout, and PR #370's connection recovery.

Value

Makes queued follow-up admission observable from Pi-owned runtime state, so clients can distinguish immediate admission from queued work without adding a second browser state machine.

Approach

• Add a typed WebPromptAdmissionReceipt with queued and queuePosition.
• Compute the position from the runtime's active/pending prompt traces when Pi accepts the prompt.
• Include the same receipt in the HTTP 202 response and prompt_accepted SSE event.
• Preserve existing Session binding, lifecycle, and child-transcript boundaries.

Validation

• Focused runtime/host tests: 40 passed, 0 failed.
• Full Node/Vitest suite: 1338 passed, 1 skipped, 0 failed; Vitest 30 passed.
• biome format / biome lint --error-on-warnings: passed.
• tsc --noEmit: passed.
• Config-contract, discipline-ledger, and Web syntax checks: passed.
• Ablation: removing queuePosition caused three admission/host regression tests to fail and removed the required queue evidence; the field was restored.
• bun is not installed in this environment, so equivalent repository scripts were run with the bundled Node 24 executable and local Biome/Vitest binaries.

Impact

• User-visible behavior: prompt admission responses/events now expose canonical queue state; no UI changes in this PR.
• Model-visible context/tools: none.
• Runtime/lifecycle: read-only admission receipt; no new queue or cancellation state machine.
• Persisted data: none.
• Compatibility/risk: additive response/event fields; existing clients can ignore them.