[Bug]: No way to send a follow-up mid-turn on mobile viewports — send button is replaced by stop and Enter-to-send is disabled below `sm`

[AMohamedAakhil]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

No phone required — the trigger is viewport width, not touch.

1. Open a thread in the web UI and narrow the window below the sm breakpoint (< 640px), or open it on a phone.
2. Send a prompt so the turn starts running.
3. Type a follow-up in the composer while the turn is still running.
4. Try to send it.

Expected behavior

The follow-up can be sent, the same as on a desktop viewport where pressing Enter mid-run submits it.

Actual behavior

There is no way to submit. The composer's primary action is replaced by the stop button while the turn runs, and Enter-to-send is disabled on mobile viewports, so the message can only be sent after the turn ends.

Root cause

The two guards overlap, leaving no send path below sm:

• apps/web/src/components/chat/ComposerPrimaryActions.tsx — if (isRunning) returns only the stop button, replacing the submit button entirely.
• apps/web/src/composer-logic.ts — shouldSubmitComposerOnEnter returns !isMobileViewport && !shiftKey, so Enter never submits below sm.

Sending mid-run is otherwise fully supported: onSend in ChatView.tsx has no isRunning guard, and isSendBusy is activeLocalDispatch !== null rather than the turn state. Desktop reaches that path via Enter; mobile has no path to it at all. So this is a missing affordance on one viewport, not a missing capability.

Notes

• This is narrower than feat: add Steer and Queue follow-up modes alongside Chat/Plan #231 (Steer/Queue follow-up modes) — it asks for no new follow-up semantics, only for the existing desktop behavior to be reachable by touch. If feat: add Steer and Queue follow-up modes alongside Chat/Plan #231 already covers the mobile affordance, feel free to close this.
• [Feature]: Add configurable follow-up behavior while a turn is running #1462 mentioned the same send/stop swap in passing while asking for queue-vs-steer configuration.
• Unrelated to Thread session stuck in running after turn interrupt — stop button becomes a no-op #4713 / [Bug]: Provider turn interrupt failures are silently swallowed — Stop generation looks successful while the turn keeps running #4524, which are about interrupt itself being a no-op server-side.

I have a small patch for this (one prop, rendering send next to stop while running when the composer has content; desktop unchanged) and am happy to open a PR if you want it.