[eric8810]

Fixes the ordering part of #546.

#run executed a related call (job.frame.path contains a waiting call id) even when an earlier emit of the same name was still queued and held by that wait. The later emit could therefore start first, violating §5.5. The queue is insertion-ordered, so #run now leaves the job queued when an earlier job of the same key is still there; the existing finally/microtask order runs them in emission order.

Added a session test where the second emit is on the waiting chain; it would log n:2, n:1 without the fix.

The close-time drop of queued local behind work (the second part of #546) is not changed here; it is a separate, narrower lifecycle question.

[eric8810]

审核结论：正确，可合并。

从根上修了：#run 在同 key 的更早任务仍排着时把带 key 的任务留在队里，等待结束的 microtask 循环按发出顺序运行。只有 emit 方式的 events.call 有 key，没人同步等 emit 监听器，在 #535 下它是 entry，看不到新的卡死风险。新测试在 main 的 session.mjs 上失败（['n:2','n:1']），加修复后通过。关闭时丢 behind 工作（#546 第 2 部分）未修，PR 已说明且不自动关 issue。

小建议（可后续）：事件协议 §5.5 的 Node 那句（docs/design-events-protocol-2026-10-18.md:199 / .en.md:199）补一句：等待链上的 emit 方式 events.call，在同名更早的被扣调用仍排队时也会等。