fix(infinity-daemon): don't flush deferred subscription events while an async tool call is in flight

[shadaj]

A subscription event (or thread report) arriving while a non-sleep async
tool call (e.g. a RAP edit_file) was awaiting its result could interrupt
that call: handle_content injects a synthetic "Tool call interrupted by
user" result and sends RAP cancellations, even though the tool actually
completed — its real result arrives later and is dropped as stale.

Root cause: thread_worker already defers deferrable synthetic events
(subscription events / thread reports / parent messages) into
pending_non_interrupt_items while waiting for an async tool result, but
the unconditional pending_non_interrupt_items.drain(..) when building
all_inputs flushed them anyway whenever any non-deferrable item was
present — e.g. a stale/duplicate tool result. In the reported session the
duplicate tooluse_LVEs… result caused the deferred tooluse_6zyy…
subscription event to be flushed, interrupting the in-flight
tooluse_y9Yx… edit_file call.

Changes in crates/infinity-daemon/src/session/thread_worker.rs:

• Add pending_non_sleep_tool_call() helper returning the id of the
  trailing unanswered non-sleep tool call; reuse it for the existing
  waiting_for_non_sleep_tool check
• Guard the pending-items drain: deferred events are only flushed when it
  is safe — no non-sleep tool call is pending, or the batch settles it
  first (contains the call's actual tool result, or a user text input,
  which deliberately interrupts). Otherwise only non-deferrable pending
  items are processed and deferrable events stay queued for a later
  iteration
• Add regression test
  stale_result_does_not_flush_deferred_events_during_async_tool_wait
  reproducing the log scenario (subscription event + stale tool result
  while an async tool is in flight); verified it fails without the fix
  and passes with it

./check.bash passes. Note: the lambda path
(infinity-agent-lambda/src/event_handler.rs) has no deferral mechanism
at all and can theoretically hit the same interruption; fixing it would
require re-enqueueing/delaying SQS messages and is left as a follow-up.

[cloudflare-workers-and-pages]

Deploying infinity with    Cloudflare Pages

Latest commit:	56ce647
Status:	✅  Deploy successful!
Preview URL:	https://0e9e9466.infinity-dc7.pages.dev
Branch Preview URL:	https://sandbox-3b52f581-f974-4530-b.infinity-dc7.pages.dev

View logs