Allow changing the model when editing a queued message

[brsbl]

The workflow

I queue several follow-ups with different models, then notice that one queued message should use a different model before it runs. I open Edit queued message so I can change both its content and execution settings without removing it from its current queue position.

Minimal flow:

1. Start a thread while an agent turn is active.
2. Queue a follow-up with a concrete model, for example:
   bb thread queue create <thread-id> "Use the alternate model for this queued follow-up." --model gpt-5.6-luna
3. Open the queued follow-ups area and choose Edit queued message.
4. Try to change 5.6-Luna to another model.

What happens today

The inline editor displays the queued message's model and reasoning values, but the Provider, model and reasoning control is disabled. Only the message content can be updated.

This limitation exists across the product surfaces:

• The UI deliberately passes executionReadOnly.
• The queued-message update contract accepts only expectedUpdatedAt and input, while creation accepts model/reasoning/service-tier/permission values: threads.ts.
• The CLI supports --model for queue creation but has no execution flags for queue update: organization.ts.

In a live repro, the queued editor's model control had disabled=true while the normal composer immediately below had disabled=false. A PATCH containing "model":"gpt-5.6-terra" returned 200 but retained "model":"gpt-5.6-luna".

What you would expect

• The queued-message inline editor allows changing the model and related execution settings before the message runs.
• Saving updates the existing queued message atomically, preserving its ID, queue position, and grouping.
• Changing model validates or resets incompatible reasoning and service-tier values using the same rules as the normal composer.
• The SDK and bb thread queue update CLI expose equivalent model, reasoning, service-tier, and permission options.

Context and alternatives

• Current workaround: copy the message, delete it, and create a new queued message with the desired model. This appends a new queue item and can change order or grouping.
• This is a feature gap, not a confirmed regression. The inline queued-message editor introduced by PR #775 has always treated execution settings as read-only; the earlier delete-and-return-to-composer workflow is not an equivalent editor implementation.
• Reproduced in bb 0.38.1-nightly.31879204424.1 and current main at 88abdac575d21e80bc13c528838e7d2060904c11.
• Investigation thread with screenshot. Compare the disabled model control in Editing queued message 1 with the enabled control in the composer below.
• The current focused test explicitly asserts the read-only behavior: ThreadDetailPromptArea.test.tsx.
• Not Active steers ignore model/reasoning changes #1860: that issue covers an editable normal-composer selection reverting or being ignored after submit/steer; here the queued editor does not offer the selection.
• Not Keyboard control for running threads: interrupt + edit-queued now, rewind later #1585: that issue requests keyboard entry to queued editing, not editing execution options.
• Suggested priority/effort: Medium. It affects multi-model queue workflows and likely requires coordinated UI, contract, SDK, CLI, and grouping behavior.

Checks

• I searched open and closed issues for the same request.
• If an agent wrote this, the body ends with > AGENT GENERATED: by <model>.

BB-Thread-ID: thr_me4d7bqdm3

AGENT GENERATED: by GPT-5