[Bug]: Submit button in Input status does nothing — enabled pending-user-input Submit is swallowed by normal-send guards

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

Summary

When a thread has hasPendingUserInput (sidebar status input), the composer shows an enabled Submit / Submit answer(s) button, but clicking it (or Enter) silently does nothing. The button enabled-state and the submit path check different preconditions.

Button enabled (apps/web/src/components/chat/ComposerPrimaryActions.tsx:147-151) only checks:

disabled={isEnvironmentUnavailable || pendingAction.isResponding || (isLast ? !isComplete : !canAdvance)}

But the submit path blocks on normal-send preconditions the button ignores:

1. apps/web/src/components/chat/ChatComposer.tsx:1890 — submitComposer early-returns on noProviderAvailable || isSendDisabled (e.g. threadDetailLoading → Messages loading, image-compression guard), before reaching the pending-user-input dispatch at :1907-1918.
2. apps/web/src/components/ChatView.tsx:5037-5064 — onSend checks !activeThread || isSendBusy || isConnecting || threadDetailLoading || sendInFlightRef.current and returns silently, before the if (activePendingProgress) onAdvanceActivePendingUserInput() branch at :5057. No toast, no threadError.

A pending-user-input answer is a lightweight thread.user-input.respond command — it needs no provider, no send context, no images. Gating it behind provider-turn sendability strands the user on the Input badge with an enabled button that drops the click.

Distinct from #5454 (server-side No active provider session stuck after restart, which also needs its fix). This is client-side and reproduces with a live session.

Steps to reproduce

1. Get an agent to call request_user_input / AskUserQuestion so the pending-user-input card + Submit renders.
2. Put the composer in any normal-send-blocked state while the card is open, e.g. thread detail loading, reconnecting (isConnecting), a send in flight (sendInFlightRef / isSendBusy), or no provider selected (noProviderAvailable).
3. Answer the question so Submit is enabled (isComplete/canAdvance true) and click Submit / press Enter.
4. Nothing happens: no dispatch, no toast, no error. Button just sits there.

Code proof: enabled Submit → form onSubmit={submitComposer} (ChatComposer.tsx:2818) → early return at :1890-1893 → preventDefault + return. Or if it reaches onSend, early return at ChatView.tsx:5037-5046 before :5057.

Expected behavior

An enabled pending-user-input Submit always dispatches onAdvanceActivePendingUserInput → thread.user-input.respond. Normal-send guards (isSendBusy/isConnecting/threadDetailLoading/sendInFlight/noProviderAvailable/isSendDisabled) must not block the pending path; only !activeThread and environment-unavailable should.

Actual behavior

Enabled Submit is swallowed silently by those guards. Zero feedback.

Impact

Major degradation or frequent failure

Start in apps/web/src/components/chat/ChatComposer.tsx at submitComposer and trace the form submission into apps/web/src/components/ChatView.tsx, especially the pending-user-input branch and its normal-send guards. Reproduce with the listed blocked states, then verify that an enabled Submit click or Enter dispatches thread.user-input.respond while environment-unavailable and missing-thread checks still apply.