Add Queue as follow-up for active chats

[sansari]

Problem

Submitting composer input while Pi is working currently treats the input as steering for the active task. Users also need a deliberate way to queue a separate task that begins only after the current work has fully settled.

This distinction matters because one task can span multiple model turns and tool executions: steering should influence that active work, while a follow-up should wait for it to finish.

Proposed behavior

• While the selected chat is actively working, show a Queue as follow-up option near the composer.
• Add a Settings preference for the default active-work submission mode: Steer or Queue as follow-up. The exact Settings section and presentation should follow the app's existing information architecture.
• Default the preference to Steer for existing and new users unless they explicitly choose Queue as follow-up.
• Initialize the composer option from that preference whenever active work begins.
• Allow the composer control to override the configured default for an individual submission.
• When follow-up is selected, submit valid composer content through Pi's follow_up RPC behavior instead of steering.
• After submission, return the composer control to the user's configured default rather than always resetting it to unchecked.
• Display pending follow-ups near the composer as read-only rows that are visibly distinct from pending steering messages.
• Preserve submitted text and attachment metadata.
• Keep follow-up state isolated to its originating chat across navigation.
• Deliver multiple follow-ups in user-submission order, one complete follow-up turn at a time.
• Keep a follow-up pending until its active work is fully settled and Pi represents it as delivered user input.
• Preserve complete failed entries for recovery or retry without silently losing or duplicating them.

Acceptance requirements

1. Selecting Queue as follow-up during active work must create a pending follow-up rather than a steering message.
2. Pending follow-ups must not affect the current task before it fully settles.
3. Multiple follow-ups must run FIFO, with each later entry waiting for the prior follow-up to fully settle.
4. Steering and follow-up entries must be distinguishable by both accessible labeling and visible presentation.
5. Follow-up text, attachments, failure handling, navigation isolation, and exact-once history delivery must receive focused test coverage.
6. Settings must allow the user to choose Steer or Queue as follow-up as the default active-work submission mode, persist that preference, and apply it to new active-work submissions.
7. A one-submission composer override must not change the persisted default, and the control must return to the configured default afterward.
8. Real Pi integration evidence must verify the follow_up lifecycle; mock-only coverage is insufficient.

Out of scope

• Escape/Ctrl+C interruption behavior
• Editing, deleting, or reordering submitted queue entries
• An upstream Pi RPC change for stable queue-entry identity or atomic dequeue