Adds a `serve` subcommand that boots an Express 5 listener with bearer
auth, host allowlist, and CORS modeled on `vscode-ide-companion/src/
ide-server.ts`. Ships only `/health` and `/capabilities` to begin with;
session/prompt/event routes will land in follow-up PRs once the per-
session ACP child-process bridge in `httpAcpBridge.ts` is wired.

Defaults to 127.0.0.1 with auth disabled so local development needs no
configuration. Binding beyond loopback (e.g. `--hostname 0.0.0.0`)
refuses to start without a token (`--token` or `QWEN_SERVER_TOKEN`).

Capabilities envelope versioned at v=1 with a `features` array — clients
should gate UI off `features`, never off `mode`, so subsequent PRs can
add capability tags without breaking older clients.

Per design issue's Stage 1 scope (~700-1000 LOC). Adds ~430 LOC of
implementation + tests in this scaffold; the remaining budget belongs
to the route wiring + bridge implementation in follow-ups.

Self-review pass on PR #3889. Two real correctness bugs and an
ergonomics gap, plus the test-coverage holes the audit surfaced. The
loudest finding ("host allowlist no-op when bind=localhost") was a
false positive — the conditional was misread; existing tests already
prove the validator is active on `localhost` binds.

Real fixes:

  - Bearer-auth timing-attack: `parts[1] !== token` short-circuits per
    byte, leaking which prefix is correct via response latency. Replace
    with SHA-256 of both sides + `crypto.timingSafeEqual` so comparison
    is constant-time regardless of token length.

  - Concurrent `spawnOrAttach` race in single-scope: two parallel
    callers for the same workspace both passed the `byWorkspace.get`
    check, both spawned, and one entry ended up orphaned in `byId`
    while the other won `byWorkspace`. Violates the
    "at most one session per workspace" invariant. Coalesce via an
    `inFlightSpawns` map: parallel callers attach to the in-flight
    promise and report `attached: true`. The slot is cleared on both
    success and rejection so a failed spawn doesn't poison the
    workspace forever. New test asserts ONE channel spawns under
    parallel calls and that retry works after rejection.

  - `Number.parseInt('1.5e10z', 10)` returns 1, so a malformed
    `Last-Event-ID` header silently passes through. Tighten
    `parseLastEventId` to `^\d+$` so anything not a pure decimal
    integer is dropped. New test exercises 'abc', '-1', '1.5e10z'.

Ergonomics:

  - `LOOPBACK_BINDS` and `LOOPBACK_HOST_BINDS` now include `::1` and
    `[::1]`. IPv6 loopback users no longer have to set a token.
    Host-allowlist allows `[::1]:port` Host headers.

Documentation:

  - `BridgeClient` doc-comment now states the Stage 1 trust model
    explicitly: agent runs as the same UID, the file-proxy methods
    are NOT a workspace-cwd sandbox, restricting them would be
    theatre. The audit flagged this as a "design gap" but the
    daemon-and-agent-on-same-host posture makes a sandbox here
    redundant — Stage 4+ remote-sandbox swaps the Client for a
    sandbox-aware variant.

SDK fix:

  - `DaemonClient.failOnError` previously called `res.json()`, which
    consumes the body even on parse-failure; the subsequent
    `res.text()` returned empty. New impl reads once as text and
    attempts JSON-parse; raw text is the fallback. New test asserts
    a `text/plain` 502 surfaces the body verbatim.

Test gap fills (audit-flagged):

  - Bridge: in-memory file-proxy tests for `BridgeClient.{read,write}
    TextFile` including line/limit slicing.
  - SSE route: `stream_error` synthetic frame on iterator throw
    mid-stream; numeric Last-Event-ID forwarded; malformed
    Last-Event-ID dropped.
  - DaemonClient: text/plain error body coerced to `body` field;
    `respondToPermission` 5xx throws; `subscribeEvents` null-body
    throws; `cancel`/`respondToPermission` URL-encode session/request
    ids that contain slashes.

Verified end-to-end with a token-required daemon: right token → 200,
wrong/missing/malformed → 401. All paths return uniform 401 messages
so a side-channel can't distinguish between "no header", "bad scheme",
and "wrong token".

Test counts: cli serve **89** (was 81, +8), sdk daemon **35** (was
30, +5). Full suites still green.

Second self-review pass on PR #3889. Three real bugs (one
correctness, one resource-cleanup, one cosmetic) plus consolidation
of the loopback bindings into a single source of truth.

Real fixes:

  - Shutdown could hang forever on a long-lived SSE consumer:
    `server.close` waits for every in-flight connection to drain,
    and a paused EventSource client never disconnects. Added a
    `SHUTDOWN_FORCE_CLOSE_MS` (5s) timer that calls
    `server.closeAllConnections()` to force-destroy stuck sockets,
    then resolves so `process.exit(0)` can run. New test asserts
    close completes well under 5.5s even when an SSE GET is in
    flight.

  - Signal-handler race during shutdown: round 1 detached the
    SIGINT/SIGTERM listeners *up front* in `handle.close()`. If a
    second SIGTERM arrived during the drain, no handler existed and
    Node's default termination ran, orphaning agent children. Switch
    to detaching at the *end* of the close path (in `finish()`):
    during the drain window the handler is still attached and the
    `if (shuttingDown) return` guard makes a second signal a no-op;
    after drain completes we can safely remove the listeners (this
    also fixes a test-suite MaxListenersExceededWarning that fired
    once we ran the runQwenServe tests >10 times in a single
    process).

  - SSE response had no `error` listener. When the underlying TCP
    socket died (RST, kill -9 on the client), the next `res.write`
    threw EPIPE and Express forwarded it to the default error
    handler, logging noisily. Added `res.on('error', cleanup)` so
    the failure is absorbed and triggers the same teardown path the
    `req.on('close')` handler uses.

Validation:

  - `createHttpAcpBridge` now throws on invalid `sessionScope` (anything
    other than `'single'` or `'thread'`) and on `initializeTimeoutMs <= 0`.
    Misconfigured callers used to silently degrade to thread behavior;
    now they fail loudly.

Cleanup:

  - The `LOOPBACK_BINDS` set was duplicated between `auth.ts` and
    `runQwenServe.ts` (round 1 missed this). Extracted into
    `packages/cli/src/serve/loopbackBinds.ts` with a single
    `isLoopbackBind(hostname)` helper. Both files now import; drift is
    impossible.

  - `res.flushHeaders?.()` lost the optional chaining. The method is
    on `http.ServerResponse` since Node 1.6; our `engines` floor is 20.

Tests added:

  - bridge: `sessionScope` validation, `initializeTimeoutMs` validation.
  - server: shutdown force-close timeout, SIGINT/SIGTERM listener
    detach-after-drain.

False positives from the round 2 audit (verified and dismissed):

  - "EventBus nextId overflow at 2^53" — theoretical only (would
    require ~9 quadrillion publishes per session). No code change.
  - "Subscribe-during-close race" — JS is single-threaded; the close()
    flag is set synchronously before the loop touches state.
  - "Queued prompts on shutdown" — by design; documented via the
    promptQueue tail comment.
  - "10MB body parser limit" — design choice for Stage 1's in-memory
    buffering model; revisit if ACP streaming lands in Stage 2.
  - "Unbounded body read in DaemonClient.failOnError" — daemon is
    local in Stage 1; the threat surface for adversarial-large error
    bodies is the same as the daemon's other unbounded buffers.

Test counts: cli serve **93** (was 89, +4), full cli **5047** (no
regressions), sdk **236** (no regressions).

Two more self-review passes on PR #3889. No correctness bugs surfaced
this time — round 3 found a HIGH-severity Windows-path claim that
turned out to be a false positive (`path.win32.isAbsolute('/foo/bar')`
returns true; verified against Node 20). Round 4 confirmed every
prior decision and surfaced one latent-but-not-currently-triggered
concurrency note.

Changes are pure documentation + a tiny optional-chain cleanup:

  - Drop `?.` on `server.closeAllConnections()` in runQwenServe.ts —
    the method exists since Node 18.2 and our `engines` floor is 20.
    The optional chain dated from before round 2's force-close timer
    landed; clean it up.

  - Help text for `qwen serve --port` now documents that port 0 means
    "OS-assigned ephemeral port" (which the implementation has always
    supported but never advertised).

  - `defaultSpawnChannelFactory` gains a comment near the spawn site
    documenting the FD-budget implication (~3 FDs per session, bump
    `ulimit -n` for many concurrent sessions) and the `stdio:
    ['pipe', 'pipe', 'inherit']` choice (child stderr lands in the
    daemon's stderr, interleaved across sessions). Both are
    Stage-1-accepted; Stage 2/4+ revisit each.

  - Comment on the bridge's `byWorkspace`/`byId` Maps documenting the
    known gap that a child crashing between requests leaves a garbage
    SessionEntry until daemon shutdown — surfaced as a per-prompt
    failure when the dead session is touched, not a hang. Stage 2's
    in-process bridge eliminates the spawned-child failure mode
    entirely so this gap goes away naturally.

  - `EventBus.subscribe` doc-comment now states explicitly that the
    returned iterator is NOT safe to drive from concurrent
    `.next()` callers — the underlying queue isn't atomic. Daemon
    usage is the sequential `for await ... of` inside the SSE route,
    so this is safe in production. Documented so a future fan-out
    consumer doesn't accidentally rely on undefined behavior.

False positives verified and dismissed (round 3 + 4 combined):

  - `path.isAbsolute('/foo/bar')` Windows breakage — `path.win32.
    isAbsolute('/foo/bar')` is true; verified empirically.
  - "Windows drive divergence" causing duplicate sessions — different
    drives are different on-disk paths; sessions intentionally
    differ.
  - "parseSseStream early-break leaks reader" — `for await ... break`
    triggers `iterator.return()` which runs the generator's `finally`
    that calls `releaseLock`. Standard JS semantics.
  - "Promise executor sync-throw fragility in requestPermission" —
    sync throws inside `new Promise(executor)` reject the outer
    promise; functionally correct, just stylistic.
  - "Force-close timeout test elapsed assertion flakiness" — assertion
    is `< 5500ms` but the natural happy-path is sub-100ms. Generous
    headroom; not flake-prone in practice.
  - "fetch reference stale after polyfill" — `globalThis.fetch.bind`
    captures at construction; tests inject `opts.fetch` instead of
    polyfilling, which is the correct pattern.

Test counts unchanged (cli serve **93**, sdk **236**); typecheck +
lint clean. STAGE1_FEATURES still matches every implemented route
1:1, fakeBridge in tests implements every HttpAcpBridge method.

Addresses the four critical findings from the PR #3889 reviewer pass:

  1. ACP `ReadTextFileRequest.line` is 1-based per spec, but the
     bridge's `BridgeClient.readTextFile` was treating it as a
     0-based slice index. A client asking for `{line:1, limit:2}`
     ("first two lines") was getting lines 2-3 — a sign-off-by-one
     bug that breaks every editor / SDK client following the ACP
     schema. Convert to 0-based via `Math.max(0, line - 1)`. The
     existing slice test was asserting the wrong behavior; updated
     to expect the spec-correct result and added a second `line:3,
     limit:2` case to lock in the offset.

  2. `modelServiceId` was accepted by the SDK + server `POST /session`
     path, forwarded into `bridge.spawnOrAttach`, and then silently
     dropped: `doSpawn` never wired it into the agent. Callers
     requesting a specific model got the agent's default and no
     indication anything was wrong. Now `doSpawn` issues
     `unstable_setSessionModel` immediately after `newSession`. If
     the agent rejects the model id, the half-initialized session is
     torn down and the spawn rejects so the caller can retry cleanly
     instead of inheriting silent drift. Three new bridge tests:
     happy path, omit-when-undefined, agent-rejection cleanup.

  3. The CORS middleware used `cors({ origin: (o, cb) =>
     cb(new CORSError(...), false) })` for browser-Origin requests.
     `cors` flows the Error into Express's error chain; without an
     explicit error handler that produces a 500 + HTML body, which
     is misleading for what is really a deterministic 403 denial.
     Replace with a tiny `RequestHandler` that checks
     `req.headers.origin` directly and returns
     `403 { error: 'Request denied by CORS policy' }` JSON. Drops
     the `cors` and `@types/cors` dependencies — there's no other
     consumer in the cli package.

  4. The SSE `stream_error` synthetic frame hard-coded `id: 0`,
     which would regress the client's `Last-Event-ID` tracker and
     trigger duplicate replays on reconnect. The frame is terminal
     and daemon-emitted — it has no place in the per-session
     monotonic sequence. Refactor `formatSseFrame` to omit the
     `id:` line when the input event has no id field, and emit
     `stream_error` without one. Test updated to assert
     `frames[1].id === undefined` while the preceding
     `session_update` still carries its monotonic id.

Tangential cleanup: `errorMessage` now formats the SSE error body
(was `err.message` only — would have shown `[object Object]` for
JSON-RPC errors mid-stream, mirroring the round-1 SDK fix).

Test counts: cli serve **96** (was 93, +3 modelServiceId cases);
existing readTextFile slice test rewritten in place. Full
typecheck + lint + suite green.

…vent.id optional (#3803)

Two more fixes from a final post-review-comment audit pass on PR #3889.
Both are subtle correctness gaps that fell out of the round-1 critical
fixes (modelServiceId apply + SSE id-less stream_error).

  - In `httpAcpBridge.ts:doSpawn`, when `unstable_setSessionModel`
    rejects after `newSession` succeeded, we tear down the entry from
    `byWorkspace` + `byId` (round 1 fix) but did NOT close the
    EventBus we'd just constructed for that entry. The agent could
    have published a session_update notification during init that
    queued in the (now unreachable) bus's ring buffer; without an
    explicit close the bus + buffer linger until the next GC cycle.
    Bounded leak (1 bus per failed spawn × 1000-event ring) but
    cleaner to close it. New regression test exercises the retry path
    after a model-rejection failure to lock in that we don't reuse
    the orphan and that subscribers on the fresh session see an empty
    iterator on immediate abort.

  - SDK `DaemonEvent.id` is now `id?: number` instead of `id: number`.
    The round-1 SSE fix made the daemon emit `stream_error` frames
    *without* an `id:` line so they don't pollute the per-session
    monotonic sequence. The SDK parser correctly returns `undefined`
    for the missing field, but the type still advertised `id: number`
    — TypeScript consumers persisting `lastSeenId = event.id` would
    accidentally store `undefined`. Made the field optional and added
    a doc comment instructing consumers to skip frames without an id.

Plus one more false-positive verified and dismissed:

  - "writeWithBackpressure Promise double-settle race": the auditor
    flagged that `res.write(chunk, callback)` could fire its callback
    after the synchronous `ok=true` resolve. Verified harmless —
    Promise double-settle is a no-op, the callback only rejects on
    error (caught separately by `res.on('error', cleanup)`), and
    multiple parallel writes register independent listener sets that
    each remove their own pair after firing.

Test counts: cli serve **100** (was 99, +1 retry-after-model-rejection
regression). SDK unchanged at 239. Full typecheck + lint + suites
green; flow re-verified end-to-end.

Critical fixes:

- server.ts safeBody() helper (BZ9uv/va/vs/wD + Bd10m + Bd1zz):
  prototype-pollution sanitization at the body-spread boundary.
  `__proto__` / `constructor` / `prototype` keys are stripped and
  the result is an Object.create(null) target. Replaces 5 sites of
  copy-pasted `typeof req.body === 'object'...` preamble + makes
  the `...(body as object)` spread sites safe.
- httpAcpBridge requestPermission (Bd1yh): per-request wall-clock
  deadline (default 5 min, configurable via
  `BridgeOptions.permissionResponseTimeoutMs`). Without this, an
  agent calling requestPermission with no SSE subscriber connected
  would hang the per-session FIFO forever. After deadline, resolve
  as cancelled + log stderr warning.
- httpAcpBridge requestPermission (Bd1z5): per-session pending
  permissions cap (default 64, configurable via
  `BridgeOptions.maxPendingPermissionsPerSession`). New requests
  past the cap resolve as cancelled with stderr warning. Prevents
  a chatty agent from growing pendingPermissions unboundedly.
- runQwenServe onSignal double-signal force-exit (Bd1y6): new
  `bridge.killAllSync()` + `AcpChannel.killSync()` method
  synchronously SIGKILLs every live qwen --acp child BEFORE
  `process.exit(1)`. Previously double-Ctrl+C bypassed the async
  bridge.shutdown() and left children running as orphans.
- server.ts SSE subscriber-limit response (Bd1zJ): 429 +
  Retry-After instead of 200 + stream_error frame. EventSource
  treats 4xx as terminal (no auto-reconnect); the previous
  200+close-stream triggered EventSource's reconnect loop,
  amplifying the load the limit existed to prevent.
- doSpawn ghost sessionId guard (Bd1zc): re-check byId.has() after
  applyModelServiceId(). The model-switch yields and can race
  channel.exited; without this, caller got HTTP 200 with a
  sessionId that 404s on every subsequent request.

Follow-ups in the same diff:

- sse.ts consumeFrames CRLF scan comment (BcRh_): the comment
  claimed the CRLF scan was bounded to `[cursor, lf)`, but Node's
  `indexOf` has no upper bound. Rewrote to describe what the code
  actually does (scan full remainder; only USE the result if it
  falls before `lf`).
- sse.ts SseFramingError export (Bd10T): typed error class for
  framing-level failures so SDK consumers can distinguish "upstream
  isn't SSE" from generic network errors via instanceof check.
  Re-exported from @qwen-code/sdk.
- protocol doc /health auth (Bctum): document the loopback
  exemption — `/health` doesn't require Authorization on loopback
  binds even when a token is configured. Matches `createServeApp`'s
  registration order.

Bd1xz (cross-session permission escalation) acknowledged as
duplicate of BUy4H — already documented as a known Stage 1 gap
under the single-user / small-team trust model; fix is Stage 1.5
must-have #3 (per-client identity + per-session permission scope).

Tests:
- New: prototype-pollution test verifies `__proto__` spread
  doesn't pollute `Object.prototype`.
- All 70 server + 55 bridge + 16 daemon-sse + 60 DaemonClient
  tests pass (203 total).

`killSync()` stubbed on every inline test channel fake; fake
bridge has `killAllSync()`.

…link, no-sessionId throw

- httpAcpBridge.writeTextFile BfFvO: dangling-symlink case. `fs.realpath`
  throws ENOENT for a symlink whose target doesn't exist, and the
  blanket catch silently fell back to writing through the symlink
  itself — `rename(tmp, params.path)` then replaced the symlink with
  a regular file, exactly the bug BX8Yw was supposed to fix. Use
  `fs.readlink` to disambiguate "truly non-existent" from "dangling
  symlink"; resolve the dangling target manually and write through
  to it so the symlink stays a symlink. Regression test added.
- httpAcpBridge BridgeClient resolveEntry BfFut: defensive throw on
  no-sessionId ACP call against a multi-session channel. ACP today
  carries sessionId on every per-session call, but if a future
  no-sessionId call lands, silently dropping it on a multi-session
  channel would be invisible.
- httpAcpBridge.test.ts BX8YO Windows skip: hard-skip via
  `process.platform === 'win32'`. Git-Bash etc. ship a `mkfifo`
  binary that degenerates on Windows (creates a regular file or
  silently no-ops), making the assertion match the wrong error
  shape. Linux + macOS coverage is sufficient for a platform-
  agnostic `!stats.isFile()` check.

BfFvW (CRLF scan comment) was already addressed in 0a4146a — the
reviewer's diff was against the pre-fix version.

Critical fixes:

- httpAcpBridge.doSpawn newSession-failure cleanup (BkwQA): if
  `connection.newSession()` throws on a freshly-created channel
  whose sessionIds set is empty, tear the channel down rather than
  leaking the empty `qwen --acp` child in `byWorkspaceChannel`
  (invisible to `sessionCount` / `maxSessions`). Channels with
  other live sessions still survive — only the truly-empty case
  reaps.
- httpAcpBridge.detachClient + killSession tombstone (BkwQP):
  detachClient no longer reaps live sessions. Scenario: A spawns
  (attached: false, hasn't opened SSE yet), B attaches
  (attachCount: 1), B disconnects → previous code reaped A's
  still-valid session. New behavior:
  * killSession({ requireZeroAttaches: true }) sets
    `entry.spawnOwnerWantedKill = true` when it bails on
    attachCount > 0 (instead of just returning).
  * detachClient ONLY decrements attachCount. It completes the
    deferred reap only when (spawnOwnerWantedKill && attachCount
    === 0 && subscriberCount === 0).
  * Both-disconnected case still works (reap completes via B's
    detachClient seeing the tombstone). Spawn-owner-alive case
    no longer reaps. Existing tanzhenxin-issue-2 test rewritten;
    new test pins the spawn-owner-alive case.
- httpAcpBridge.writeTextFile mode preservation (BkwQW): stat the
  target before writing; if it exists, chmod the tmp file to the
  preserved mode (and chown owner/group — best-effort, EPERM
  ignored for non-root). Previously a 0600 secret/config edit
  would downgrade to umask-default 0644, exposing contents to
  other local users.
- bridge.respondToPermission option-ID validation (BkwQI): new
  `InvalidPermissionOptionError` thrown when the voter's `optionId`
  isn't in the set of options the agent originally offered in the
  `permission_request` event. PendingPermission now carries
  `allowedOptionIds`. Server route catches the error → 400 (vs.
  404 for unknown requestId). Prevents authenticated clients from
  forging hidden outcomes like `ProceedAlways*` when the prompt's
  `hideAlwaysAllow` policy intentionally suppressed them.

Doc fixes:

- httpAcpBridge top-of-file (BkdCg) + types.ts ServeMode (BkdC8):
  rewrite the "each session spawns its own qwen --acp child"
  framing to match the actual Stage 1.5 multi-session-per-channel
  architecture (one child per workspace, sessions multiplex via
  `connection.newSession()`).

…g tests + 1 doc

- writeTextFile mode-bits race (Blehd): the BkwQW fix preserved
  mode via `chmod` AFTER `fs.writeFile`, leaving a brief window
  where a `0600` secret-edit was readable at the directory's
  umask default (commonly `0644`). Now pass `mode` to writeFile
  directly so the file is CREATED with the preserved mode atomically
  via the `open(O_CREAT, mode)` syscall. The post-write `chmod`
  remains as belt-and-suspenders against a tight operator umask
  (POSIX `mode & ~umask` could drop bits we wanted preserved).
- httpAcpBridge.test.ts: new bridge-level test for the BkwQI
  `InvalidPermissionOptionError` path (Blehk). Forge a vote with
  an `optionId` not in the agent-offered set; assert the throw
  AND that the pending permission survives so a valid vote can
  still resolve it.
- server.test.ts: new route-level test for the BkwQI 400 mapping
  (Blehl). Fake bridge throws `InvalidPermissionOptionError`;
  assert response is 400 with `code: 'invalid_option_id'`,
  `requestId`, and `optionId` in the body.
- commands/serve --http-bridge help text (Bk59I): updated to
  reflect Stage 1.5 multi-session — "one `qwen --acp` child per
  workspace, with multiple sessions multiplexed via the agent's
  native `newSession()`" (was: "per-session child").

…ody-read rejection (BlqF_)

Some fetch impls (undici on abort) reject the in-flight `reader.read()`
with an AbortError after `reader.cancel()` fires. Pre-fix that
rejection bubbled to the consumer's `for await`, contradicting the
"abort cancels cleanly" public contract — code that called
`controller.abort()` to wind a subscription down saw an unexpected
throw on the next iteration.

Wrap `reader.read()` in try/catch:
- if `signal?.aborted` is true → treat the rejection as clean
  completion (return from the generator)
- otherwise re-throw, so real upstream failures (network drop,
  unexpected close, malformed body) still reach the consumer

Two regression tests pin the guard's scope: signal-aborted
mid-stream returns cleanly with the frames received so far; a
non-abort `streamController.error(...)` still bubbles via `rejects.toThrow`.

…listener (BmJT1)

Pre-fix: `publish()`'s eviction path deleted the sub from `this.subs`
but never invoked `dispose()`, leaving the AbortSignal abort-listener
registered in `subscribe()` attached. Because the consumer is by
definition stalled (that's what caused the overflow), `next()` /
`return()` never fire to detach the listener through the iterator
path. Closures over the queue + sub stayed live until the AbortSignal
itself went out of scope.

Under attack (thousands of opened-then-stalled SSE clients), this
amplified into significant heap retention.

Fix: store `dispose` on `InternalSub` and invoke `sub.dispose()` from
the eviction path. The same closure used by the abort listener / the
iterator's `next()`/`return()` cleanup now runs through the
eviction path too — idempotent through `disposed` so a
post-eviction abort or iterator-return is still safe. Regression
test pins the post-eviction abort + publish path producing zero
side effects.

…broken by multi-session refactor (BkUyD)

The Bd1y6 design promised a second SIGINT/SIGTERM during graceful
drain synchronously SIGKILLs every live agent child via
`bridge.killAllSync()` before `process.exit(1)` — the operator-
visible "kill it now" path for a wedged child ignoring SIGTERM.

The Stage 1.5 multi-session refactor (commit 6a170ef) inadvertently
broke this. `shutdown()` snapshots `byWorkspaceChannel` then CLEARS
the map BEFORE awaiting the per-child SIGTERM-grace kills (up to
~10s each). If the operator double-taps mid-window, `killAllSync()`
snapshotted from the now-empty `byWorkspaceChannel.values()` and
silently no-op'd — the for-loop iterated nothing, `process.exit(1)`
fired, and any child still inside its SIGTERM grace window was left
orphaned with dangling pipes. Exactly the scenario the force-kill
path was added to handle.

Fix: introduce a separate `liveChannels: Set<ChannelInfo>` as the
source of truth for "channels with potentially-alive child
processes". Added in `getOrCreateChannel` alongside
`byWorkspaceChannel.set(...)`; removed only when `channel.exited`
fires (the OS-level "really dead" signal). `killAllSync()` now
iterates `liveChannels`, so a mid-shutdown second signal still
sees every still-alive child regardless of where the graceful
drain currently is. Other paths (`killSession` last-session reap,
`channel.exited` crash handler) automatically remove via the same
exit-handler hook.

Regression test:
- Builds two sessions on different workspaces
- Replaces each channel's `kill()` with a never-resolving Promise
  (simulating stuck SIGTERM grace)
- Calls `bridge.shutdown()` to enter mid-drain state
- Yields twice so shutdown's sync prefix runs (clears
  byWorkspaceChannel, starts the never-resolving awaits)
- Calls `bridge.killAllSync()` — pre-fix this saw an empty
  `byWorkspaceChannel` and the spy array would have been empty;
  post-fix both channels' `killSync` is invoked.

(tanzhenxin's other observation — channels-package duplicate ACP
bridge — is the same architectural concern as chiga0 finding 1+5,
already tracked under existing FIXME(stage-1.5) markers. No code
change in this commit for that.)