fix(app): restore queued follow-up (Queue/Steer) setting in web UI

[chaosmanage]

Issue for this PR

Closes#44108

Type of change

• Bug fix

What does this PR do?

This fixes the web UI (opencode web, everything in packages/app). TUI/CLI are not touched. Since commit ae7e2eb, sending a message while the agent is busy in the web UI always steers into the current run, because queued follow-ups were disabled there: the persisted general.followup setting was coerced to "steer" in the accessor, setter, and a rewrite effect, and the settings row was deleted.

The queue machinery itself was never removed from the web app — the per-session persisted queue store, the flush-when-idle effect, the queued-messages dock, and the composer shouldQueue/onQueue wiring in pages/session.tsx all still work as soon as the setting can be "queue" again.

So this PR:

• reverts that coercion in packages/app/src/context/settings.tsx (exact inverse of ae7e2eb's hunk)
• restores the Follow-up behavior row in packages/app/src/components/settings-general.tsx (also verbatim from before)
• adds the same row to packages/app/src/components/settings-v2/general.tsx (the default dialog), following the existing LanguageSetting/ShellSetting pattern, since v2 never had the row

After this, users can pick General → Follow-up behavior → Queue in the web UI settings, and busy-session messages will queue up FIFO and run after the current turn finishes instead of steering.

The i18n keys were never removed, so no translation changes are needed. #33247 covers the broader redesign (per-message modes, wrap/halt-steer); this intentionally stays minimal and can be closed if that lands first.

How did you verify your code works?

Two of the three hunks are byte-for-byte reverses of a previously working, shipped implementation, so behavior matches the pre-ae7e2eb Queue mode. I did not run the app locally; please lean on CI for typecheck/tests/i18n parity.

Screenshots / recordings

Settings-only UI change restoring a previously existing row; happy to attach a recording if useful for review.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[chaosmanage]

Due-diligence on why reverting ae7e2eb should be safe — posting here so maintainers can correct me if there was a non-obvious reason:

• ae7e2eb's message says "remove queued follow-ups for now"; it references no bug or failing test, and its two commit comments are only users asking for the feature back.
• The queue machinery was kept fully intact and even maintained after removal (session-followup-dock.tsx received a locale plural-rules update in Aug 2026), which suggests it wasn't ripped out for being defective.
• Two earlier community restores of exactly this setting (fix(app): restore queued follow-up setting #29110, fix(app): restore queued follow-up setting #29265) were closed by their authors / an automated cleanup bot respectively — never reviewed down with "this doesn't work". fix(app): restore queued follow-up setting #29265 passed compliance and had community support before the cleanup sweep.

If queue mode was disabled for a reason I couldn't find (e.g., a UX problem or a subtle send-path bug from that era), I'd appreciate a pointer — happy to close this in favor of the fuller treatment in #33247 instead.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[chaosmanage]

Heads up for maintainers: the required checks (typecheck, unit/e2e, nix-eval) are sitting at action_required — this is my first PR here, so they need a one-click "Approve and run workflows" to start reporting. Happy to address anything that fails once they run.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍