fix(mobile): gate queued follow-ups on attachment uploads

Review follow-ups on the media chain.

onSendMessage grew an upload block guard from #8978 but onQueueFollowUp did
not, and upstream has no onQueueFollowUp to carry the change. Both UI entry
points gate on canSend today, so this is currently unreachable — but a future
caller would queue a follow-up mid-upload and start a second transfer of the
same bytes alongside the background worker's.

The collapsed queue pill also hardcoded its accessibility label while its send
sibling and the toolbar button both surface the block reason, so a failed
upload disabled the pill with nothing for VoiceOver to read.

Author: rynfar

apps/mobile/src/features/threads/ThreadComposer.tsx

@@ -1797,7 +1797,7 @@ export const ThreadComposer = memo(function ThreadComposer(props: ThreadComposer
                     />
                     {canQueueFollowUp ? (
                       <ControlPill
-                        accessibilityLabel="Queue follow-up"
+                        accessibilityLabel={attachmentBlockReason ?? "Queue follow-up"}
                         icon="arrow.up"
                         variant="primary"
                         disabled={!canSend || isMutatingSessionInputQueue}

apps/mobile/src/state/use-thread-composer-state.ts

@@ -776,6 +776,21 @@ export function useThreadComposerState() {
     const attachments = draft.attachments;
     if (text.length === 0 && attachments.length === 0) return null;
 
+    // Same gate onSendMessage applies: queueing while an upload is still in
+    // flight would start a second transfer of the same bytes alongside the
+    // background worker's.
+    if (
+      composerAttachmentUploadBlockReason({
+        environmentId: selectedThreadShell.environmentId,
+        attachments,
+        connected: selectedEnvironmentRuntime?.connectionState === "connected",
+        serverConfig: selectedEnvironmentRuntime?.serverConfig ?? null,
+        states: appAtomRegistry.get(composerAttachmentUploadsAtom),
+      }) !== null
+    ) {
+      return null;
+    }
+
     if (attachments.length > PROVIDER_SEND_TURN_MAX_ATTACHMENTS) {
       Alert.alert(
         "Too many attachments",