#3108: bug: queue and draft-only sessions can be lost across refresh, tab restore, and zero-message boot paths

Summary

Unsent work is still too easy to lose across refreshes, tab detours, and zero-message session restore paths.

This shows up in two closely related ways:

1. queued follow-up messages are not durable enough when the browser tab reloads or the user navigates away and back
2. draft-only sessions with zero visible messages can be treated as disposable scratch pads and dropped on boot restore, even though the user has unsent composer text/files

User Impact

• queued turns can disappear after refresh/tab switching
• starting a new session, typing, then switching tabs or refreshing can lose unsent work
• users must retype instructions or reconstruct queue state from memory

Root Cause Candidates

A) Queue persistence is too narrow

Historically the queue path relied on sessionStorage only. That makes it fragile across certain browser/tab restoration paths.

B) Restore path and write path can diverge

Even when queue persistence is hardened on write, the restore path also needs to read the same durable source; otherwise the extra durability never actually helps on reload.

C) Zero-message draft-only sessions are misclassified

Boot restore logic can treat message_count == 0 sessions as blank scratch pads unless it explicitly checks whether composer_draft still contains unsent text/files.

Suggested Fixes

1. Mirror queue persistence to both sessionStorage and localStorage
2. Use a shared restore helper so the load path can fall back to the durable copy
3. Preserve zero-message restored sessions when composer_draft.text or composer_draft.files is non-empty
4. Add regression tests for:
   • queue survives refresh/tab detour
   • queue restore clears only stale items
   • zero-message draft-only session is preserved on boot

Affected Area

• static/ui.js
• static/sessions.js
• static/boot.js

Notes

This is a UX bug, not just a polish issue: it can cause real instruction loss during normal use.