fix(platform): clear the full-page drop overlay after a composer drop

[larryro]

Summary

Dragging a file onto the chat composer left the full-page "Drop files here to upload" overlay stuck — covering the page and blocking all interaction until a manual reload. The file still attached (the composer handled the drop), but the overlay never dismissed.

Root cause

The full-page overlay is PageDropOverlay, driven by the window-level usePageFileDrop hook (chat-interface.tsx:480/1159). The chat composer's FileUpload.DropZone calls e.stopPropagation() on its drop (file-upload.tsx:187) so the file lands on the composer rather than the window handler. But stopPropagation() also prevents the window's bubble-phase drop listener from ever running — so isDragOver / dragDepth never reset, and the overlay sticks until reload. The hook's own design note even anticipated the "region zone wins" routing, but missed that the reset then never fires.

Fix

Reset the overlay state (dragDepth = 0; setIsDragOver(false)) in a capture-phase window drop listener. The capture phase runs window → target, before any child's stopPropagation(), so the reset always fires regardless of who handles the drop. The existing bubble-phase handler still owns the upload for drops that don't hit a region zone, so there's no double-upload.

window.addEventListener('drop', onDrop);                 // bubble: upload (non-region drops)
window.addEventListener('drop', onDropResetCapture, true); // capture: reset always

Testing

• New regression test in use-page-file-drop.test.ts: drops onto a child element that stopPropagation()s and asserts (a) the overlay clears and (b) the window handler does not also upload. Fails without the fix, passes with it.
• app/hooks/use-page-file-drop.test.ts — 5/5 pass · platform tsc 0 · lint 0

Notes

• Pre-existing frontend bug — unrelated to the recently-merged backend attachment PR (feat(sandbox): deliver chat attachments to sandboxed external agents #2119); separate PR as discussed.