Fix attachment uploads: accept-aware input selection, upload-settle wait, scoped stop detection, reply-baseline wait

[adossey]

Summary

Attachment uploads to chatgpt.com hung forever at 0% (file tile renders, spinner never moves, no network request), and long-thinking models returned empty text. Debugging against a live session via CDP surfaced five compounding bugs; this PR fixes all of them.

1. Documents were fed to the image-only file input (the 0%-spinner root cause)

setFileInputFiles tried file inputs in reverse DOM order. chatgpt.com ships three inputs — #upload-files (the composer), #upload-photos (accept="image/*"), #upload-camera (accept="image/*") — so reverse order picks #upload-camera. A document dropped into an image-only input enters the site's image pipeline, whose decode rejects uncaught inside uploadFile (verified via Runtime.exceptionThrown): the tile renders in Uploading state and no upload request is ever issued. Both backends (Chrome CDP + Electron) now read each input's accept attribute and prefer accept-compatible inputs; image-only inputs are used only when every file is an image.

2. Send raced in-flight uploads

query() clicked send immediately after attaching. Providers disable send while uploads are in flight, so every send strategy failed within seconds (send_not_triggered) while tiles were legitimately still uploading. New #waitForUploadsSettled() runs between typing and sending: polls for a visible enabled send button with no in-flight upload indicator in the composer, held stable across polls; byte-scaled timeout (2min base + 1min/MB, 15min cap); surfaces attachment_upload_failed / attachment_upload_timeout with data instead of a misleading send error. Emits the existing uploading_files progress phase.

3. Stop-button detection matched sidebar history ("…Cancellations")

The stop selector includes button[aria-label*="cancel" i], which matched sidebar history rows for a conversation titled "JetBlue West Coast Cancellations" — every send failed with already_generating. Stop lookups (#clickSend guard, #clickVisibleStop, #waitForAssistantStable) are now scoped out of nav/aside/[role=navigation]/history containers. Additionally, when a provider replaces the send button with the stop button while responding, the absence of a send button no longer counts as "send enabled" — so generating is correctly detected during long thinking phases.

4. Empty replies from reasoning models

#waitForAssistantStable accepted pre-existing page text as "the reply" after 2.5s of stability — models that think silently for minutes (e.g. "Pro thinking") returned success with empty/garbage text. Completion now requires a new assistant message beyond the count captured when waiting began, with escape hatches for selector-less providers (45s fallback grace) and a baseline-glitch guard (2min of stable, non-generating quiet).

5. Closed tabs were never pruned (silent 10-minute hangs)

A Target.targetDestroyed listener was registered, but Target.setDiscoverTargets was never enabled — Chrome never emits those events without it. Closing a tab left a zombie record whose dead session made every evaluate throw; waitForPromptVisible swallowed the errors and spun silently until full timeout. Discovery is now enabled, and waitForPromptVisible surfaces tab_target_lost after repeated consecutive evaluate failures so callers can recreate the tab.

Verification

• Live against chatgpt.com (Chrome CDP backend): attach → upload completes (POST /backend-api/files → CDN PUT → process_upload_stream) → send → waits through an extended "Pro thinking" phase → returns the exact reply text. Previously: tile frozen at 0% and send_not_triggered / already_generating / empty-text results.
• npm test: 163/163 pass.
• Diagnosis method, for the curious: attached to the live session over CDP, confirmed change/input events fire with correct File+mime, zero upload fetches from the page, captured the uncaught rejection in the site's uploadFile, and bisected the three file inputs to find only #upload-files triggers the real upload chain.