fix(desktop): sync the composer queue across windows (#46732)

[furancis]

What does this PR do?

Fixes cross-window contamination of the composer prompt queue: with several desktop windows open, a prompt queued in one window could silently vanish, resurrect after being drained, or auto-drain and submit from a window the user never typed in.

Root cause

Every desktop window boots $queuedPromptsBySession from the same localStorage key (hermes.desktop.composerQueue.v1) and then never syncs again:

• no storage event listener anywhere — each window keeps a private, diverging snapshot of the entire cross-session queue map;
• every save() writes the window's whole snapshot back, so window B's next write clobbers entries window A enqueued after B booted;
• runDrain() picks the entry from the rendered React slice, so an entry another window already drained can double-submit;
• the auto-drain loop runs in every window, so whichever window's drain fires first sends the prompt — regardless of where the user typed it.

Fix (3 small pieces, no architecture change)

1. composer-queue.ts — listen for storage events on the queue key and reload the atom. The event only fires in non-writing windows, so there's no self-echo to guard against.
2. writeSession() / migrateQueuedPrompts() — merge over load() (the live persisted map) instead of the in-memory atom, so a save can never revert a write that landed between sync events. The storage event is async in real browsers; this closes the same-frame race.
3. runDrain() — pick the entry from getQueuedPrompts() (live store) instead of the rendered slice, so a cross-window removal observed at send time stops a double-submit. Also drops a now-unneeded queuedPrompts dependency from the callback.

Single-window behavior is unchanged: load()/save() round-trip identical data and the listener never fires without a second window.

Related Issue

Fixes #46732
Related: #46194 (queued follow-up state leaking across session switches — the storage-sync half of that report is covered here; the composer UI-state half is separate), #39086, #40394

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

How was this tested?

• 6 new vitest cases in composer-queue.test.ts (cross-window sync (#46732) describe block):
  • adopts another window's write into the local atom
  • does not clobber another window's entries when saving its own
  • merges over live storage even without a storage event (same-frame race)
  • drops entries locally once another window drains them
  • resyncs on full storage clear (event.key === null)
  • ignores storage events for unrelated keys
• npx vitest run src/store/composer-queue.test.ts → 20/20 (14 existing + 6 new)
• npx vitest run src/app/chat/composer → 42 pass / 1 fail — the failing AttachmentList renders empty list without error fails identically on a clean main checkout (verified via stash), pre-existing and unrelated
• tsc -p . --noEmit → clean
• npx eslint on all three touched files → no issues
• Manual repro on Windows 11: two windows on the same profile, queue a prompt in window A while its session is busy → before: window B's drain loop could submit it / A's entries disappeared after B queued anything; after: the queue stays consistent in both windows and drains exactly once.

Screenshots (if applicable)

N/A — behavioral fix; the symptom is prompts appearing/vanishing across windows.

Checklist

• My code follows the repository's style guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective
• New and existing unit tests pass locally with my changes

[teknium1]

Thanks for isolating the stale whole-map persistence path; current main still has that defect in apps/desktop/src/store/composer-queue.ts:47-60.

Problems

• apps/desktop/src/store/composer-queue.ts:67 reloads storage, but callers already computed queue from their local queueFor(sid). Two windows appending or editing the same session still replace that session array with competing stale versions. The new tests at composer-queue.test.ts:173-195 only cover different session ids.
• apps/desktop/src/app/chat/composer/hooks/use-composer-queue.ts:195 reads live state, but both windows can select the same entry and call onSubmit before either reaches removal at line 213. The lock is a renderer-local ref, while every idle renderer schedules auto-drain (use-composer-queue.ts:260-316), so this does not prevent a concurrent double submit.

Suggested changes

• Add a cross-window-safe same-session mutation/claim protocol and test two independent renderer contexts for concurrent same-session writes and drain attempts.

Automated hermes-sweeper review.

[teknium1]

queue was computed from queueFor(sid) before this reload. Two windows concurrently appending or editing this same sid still each replace next[sid] with a stale array, so the final write loses the other mutation. Please derive or claim the per-session mutation from authoritative current state and cover same-session concurrency.

[teknium1]

This is not a cross-window drain claim: two renderers can both read this entry and invoke onSubmit before either reaches removal below. drainingQueueRef is local to one hook instance. Please add shared ownership/claiming before submit and a two-renderer regression test asserting exactly one submission.