fix(chat-flow): serialize per-chat processing, end flow on dead-leaf nodes (v1.0.3)

[rmyndharis]

Summary

Two robustness fixes to chat-flow, released as v1.0.3.

Per-(session, chat) serialization

processMessage read flow state, navigated, then wrote it back with awaits in between. Two near-simultaneous messages for the same chat could both read the same state and race the write — a double greeting on first contact, a lost path advance, or a resurrected leaf. Processing is now chained per ${sessionId}__${chatId} through a promise lock (settled tail so a rejection can't wedge the chain; self-evicting when the chain drains). The bounded invalid-path re-process recurses on the locked body, not the public entry, to avoid waiting on its own pending chain entry.

Dead-leaf flow end

If a config edit left an in-flight user parked on a node that no longer has any options, every subsequent message hit the fallback branch, replied "Invalid option", and re-saved the state — an endless loop until the 15-minute expiry. When the resolved node has no options, the flow now ends cleanly (state cleared) so the next trigger starts fresh. The legitimate "typed an option that isn't in the menu" case (node still has options) is unchanged.

Tests

• New: concurrent messages for the same chat send the greeting exactly once.
• New: a stored path landing on a now-leaf node ends the flow instead of looping.
• Full suite green, tsc --noEmit clean, bundle packages cleanly. The public processMessage signature drops the internal depth arg (it was always defaulted; no caller passed it).