feat(serve): queue frames per session on each connection

[Moikapy]

Part of #144, section B: "per-connection frame handling lets different sessions on one connection run concurrently". This fixes Ossuary sessions queuing behind each other on its one WebSocket.

Before and after

• Before: attach_client chained every frame on a connection onto one queue. A long prompt.submit on session A held up session B's submit, and even health and session.list, until A finished.
• After: frames are queued by params.session_id.
  • Frames for one session keep their arrival order and reply order.
  • Different sessions, and frames that name no session (health, session.list, session.create, which share one lane), no longer wait behind other sessions' runs.
  • prompt.abort still bypasses every queue, and queued submits are still registered for cancellation when they arrive.
  • A lane is dropped once it goes idle, so the map doesn't grow with every session ever used.

Consequence: replies from different sessions can now interleave on one socket, so clients must match replies by JSON-RPC id. Ossuary already does this (the pending map in apps/ossuary/electron/gateway-session.ts).

Safety of concurrent runs: the per-session SessionManager in prompts.ts already runs different sessions concurrently across connections, and each run's events go through its own on_event, tagged with its session_id (#136). The doc line saying runs are "serialized so fan-out stays tagged" was stale, and this PR replaces it.

Tests

• New: sessions A and B share one connection, and A's model call hangs. B's submit and a health frame both complete before A, and A completes once released. The reply order is b, health, a.
• Changed: the "binary prompt.abort bypasses the queue; a health frame that mentions abort does not" test now gives its health frame the same session_id, so the frame still shares the submit's queue and the test still checks that text mentioning prompt.abort isn't treated as an abort.
• Mutation check: a single queue for all frames (the old behavior) makes the new test fail, and per-frame lanes with no same-session ordering make the abort-ordering test fail.

Checks

• tsc --noEmit: clean.
• vitest: 708/712 pass. The four failures happen only in this container and fail identically on clean main: serve_transport "::1" (no IPv6), plus three fetch/SSRF tests that need DNS (getaddrinfo ENOTFOUND example.com).
• vitepress build docs: passes. docs/architecture/serve.md and the CHANGELOG are updated.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LHQAfXHofy6QkAgmfmJava

---

Generated by Claude Code

[cursor]

PR #183 — Risk: MEDIUM (per-connection serve queue becomes per-session lanes; 4 files, +102/−11. Runtime scheduling, not docs-only, so not LOW. Auth, bind, token, tool permissions, and public exports are unchanged, so not HIGH.)

Findings: Critical 0 / Warning 0 / Suggestion 1 (src/serve/server.ts:262, pin in-flight session bags so a concurrent session.create cannot LRU-evict them)
Regressions of settled findings: none
Not reviewed: none
Action: escalated to @Moikapy
Log: 2026-10-08T15:50:52Z, escalated, MEDIUM runtime scheduling change; CI still running (typecheck 20/22, ossuary, wiki_lint); auto-merge left off; head commit author is claude, not @Moikapy

@Moikapy — this lets different sessions, and frames with no session_id, run at the same time on one lich serve socket. Same-session order, the prompt.abort bypass, idle-lane deletion, and Ossuary matching replies by JSON-RPC id look right. I did not find a security or correctness break. CI has not finished, and the head commit is authored by claude, so I did not enable auto-merge.

  

_{Sent by Cursor Automation: PR REVIEW}