fix: handle tool results that arrive before tool calls

[jackyangming]

Network ordering issues can cause tool result messages to arrive before their corresponding tool call messages. Without this fix, results are discarded and tools stay in 'running' state forever.

This fix adds a pendingToolResults mechanism to temporarily store early results and apply them when the tool call arrives.

[YOMXXX]

Heads-up: PR #1287 is a complementary fix on a different ordering axis — it handles the race between the prompt RPC response and the trailing session/update notifications (i.e. response can arrive before the last update). #1281 here handles tool-result arriving before tool-call within the update stream. Both can fire in the same session; recommend reviewing together so the turn-complete state machine ends up consistent across both axes.

[jackyangming]

Thanks for the heads-up! I've reviewed #1287 and understand the complementarity:

• fix(acp): two-signal turn-complete state machine (response + updates) #1287 handles the cross-stream race (RPC response vs update notifications)
• fix: handle tool results that arrive before tool calls #1281 handles the in-stream race (tool-result vs tool-call within the update stream)

Both can fire in the same session. My pendingToolResults mechanism operates at the reducer level (processing individual messages), while your two-signal state machine operates at the turn level (ACPBackend). They work at different layers and should not conflict.

Happy to coordinate if any adjustment is needed to keep the state machine consistent across both axes.