fix(host): drain the dispatcher queue to empty when a step throws

[mtskf]

Summary

createDrainingDispatcher had no failure policy for a throwing step: it reset draining in a finally but neither cleared nor re-drained queue, so an event enqueued re-entrantly before the throw sat there until the NEXT external dispatch — a stale replay, arbitrarily later, against a state it was never computed for. This decides the policy explicitly: continue-draining.

Changes

• host-session-core.ts — the dispatcher catches per step, drains the queue to EMPTY, and only then lets the failure reach the caller: a lone error rethrown as-is (identity and triage payload intact, falsy values included), several as an AggregateError. draining is still released in a finally, before the rethrow, so a caller that dispatches from its own catch handler starts a fresh drain.
• The JSDoc records the decision and both rejected alternatives: CLEARING the queue is unsafe by construction here — applyEditSettled is the write lock's only release site (edit-settled-barrier.ts), so dropping one strands the lock and the side channels deferred behind it; DOCUMENTING the "effects never dispatch synchronously" invariant leaves it unenforced by anything. It also states what continuing does NOT do (it is scheduling, not transactional recovery: the failed event's remaining effects stay abandoned, and a throwing applyEditSettled transition still strands the lock — a cost owned by HostSessionStepDeps.commitTransition), and that liveness is unchanged (no effect may re-dispatch unconditionally).
• effect-executor.ts — the two comments asserting "createDrainingDispatcher has try/finally and NO catch" now say it rethrows once the drain is empty. Their substance is unchanged: the throw still escapes to the caller, so the unhandled-rejection reasoning holds; only its timing moves to the end of the drain.
• Tests — four new createDrainingDispatcher traces (drain-to-empty + error identity + no residue on the next dispatch, AggregateError for multiple failures, a falsy throw not read as a clean drain, and no throw when every step succeeds). host-session-step.test.ts's residue pin, which explicitly asked to be updated consciously if the policy changed, now pins the new behaviour.

Related

• TODO: createDrainingDispatcher has no failure policy for a throwing step (out-of-scope finding from the /review-plan rounds on the settle-effects-throw barrier fix).
• Design reviewed by Codex, which reached the same verdict independently and contributed the liveness note and the "attempt, not success" framing of the contract.

Test Plan

• pnpm compile — clean
• pnpm test:unit — 5367 passed
• Non-vacuity: the three new policy assertions are red on the pre-change dispatcher (seen stops at ["a"]; the multi-failure case throws the first Error instead of an AggregateError)
• pnpm lint — clean for the touched files
• pnpm build + pnpm package (vsix audit: 22 entries, no violations) + code --install-extension --force