fix(stream-management): handle queue desync after page reload

[mremond]

Problem

When a browser page or app reloads, the outbound queue (outbound_q) is not persisted but the server maintains its acknowledgment counter. On session resume:

1. Server sends <resumed h="N"/> with the real counter value
2. Client has outbound=0 and empty outbound_q (fresh instance)
3. ackQueue(N) tries to remove N items from empty queue
4. shift() returns undefined, causing crash on item.stanza

Solution

Add a guard in ackQueue() that:

• Detects when queue is empty but server reports higher h value
• Resyncs the outbound counter to match server's value
• Breaks out of the loop to prevent the crash

Trade-offs

I am aware the proper fix would be to persist the outgoing queue to storage to avoid any potential message loss. However, this minimal fix:

• Works without message loss in the vast majority of cases (the window between send and ack is typically milliseconds)
• Avoids having to micro-manage the session store with queue serialization
• Keeps the fix simple and non-invasive
• Properly resyncs counters to prevent future desyncs

In-flight stanzas (sent but unacked at reload time) would still be lost, but this is an edge case that would require significant additional complexity to handle properly (serializing XML elements to storage, handling duplicates if server did receive them, etc.).

[singpolyma]

How are you resuming (to get resumed with any value) if not persisting the session data?

[mremond]

Well, you always need to have the id to reattach. The point that in the case of failure that is triggered there, you have already lost the message AND are force to reconnect from scratch.

[singpolyma]

So you're storing the SM id but none of the other SM data?