Make the drop gate a state question, not a geometry one

The gate that decides whether a native file drop is accepted has been wrong
twice in opposite directions, both times because it tried to be precise about
*which points* a dialog covers:

- Round 1 asked `el.contains(elementFromPoint(x, y))` and was handed the inner
  xterm host while the overlays are siblings, so the always-rendered
  Following/Paused button made the terminal's top-right corner permanently
  refuse drops.
- Round 2 replaced that with "is a blocking overlay painted here?" and deleted
  the document-wide gate. `elementFromPoint` returns the *topmost* element, and
  ToastHost is z-[60] against the Modal backdrop's z-50 in the same stacking
  context — so a refused drop pushed a toast, the toast covered the dialog, and
  the next drop released on it was reported clear and landed in the directory
  the dialog was covering. The gate armed its own hole.

Split the two questions instead of merging them:

- Geometry answers *whose* drop it is (rect hit test, unchanged), so exactly
  one listener speaks for a drop and a hidden pane's zero-size rect still keeps
  TerminalView and FilesTab from both firing.
- `dropIsBlocked` answers whether the app should take a drop at all —
  document-wide, no z-index in it. While a modal or blocking overlay is on
  screen anywhere, every drop is refused.

There is no `elementFromPoint` call left, so no future overlay can become a
drop hole by being painted high enough and no chrome can become a dead zone by
being painted at all. The cost is over-refusal while a dialog is open, in a
state the user entered deliberately, announced, writing nothing.

Also:
- `[aria-hidden="true"]` no longer disqualifies a blocker. It is not a
  visibility statement (it sits on visible decorative content), so a blocker
  nested in such a wrapper would have silently stopped blocking.
- Modal drops `data-blocks-drop` when its pane hides, and moves focus out of
  itself rather than leaving it inside a `display:none` panel.
- The refusal notice stays `kind: "info"` (an expected refusal is not an
  error, and an error card never auto-dismisses) and carries a `dedupeKey`, so
  repeated refusals replace rather than stack.

Tests: mutation-checked against the previous implementation — four in
dropTarget.test.ts, two in each of TerminalView/FilesTab, two in Modal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GBq2rGum6GX7xXgsas1fDc

app/src/components/terminal/TerminalView.test.tsx

@@ -292,9 +292,12 @@ describe("TerminalView — where a dropped file lands", () => {
     return view;
   }
 
-  /** jsdom has no `elementFromPoint`, so the z-order branch is unreachable
+  /** jsdom has no `elementFromPoint`, so a z-order branch is unreachable
    *  unless a test supplies one — which is exactly how a gate that refused
-   *  every drop under the Following toggle shipped through this file green. */
+   *  every drop under the Following toggle shipped through this file green.
+   *  The gate asks no per-point question any more, but the tests below still
+   *  install one and feed it the most misleading answer available, to pin
+   *  that the routing does not change when it is there. */
   function stubElementFromPoint(top: Element | null) {
     Object.defineProperty(document, "elementFromPoint", {
       configurable: true,
@@ -369,7 +372,8 @@ describe("TerminalView — where a dropped file lands", () => {
     delete (document as Partial<Document>).elementFromPoint;
   });
 
-  it("refuses — and says so — when a dialog is painted over the drop point", async () => {
+  it("refuses — and says so — while a dialog is open", async () => {
+    useAppState.setState({ toasts: [] });
     await mountWithLayout();
     const backdrop = document.createElement("div");
     backdrop.setAttribute("data-blocks-drop", "true");
@@ -383,13 +387,52 @@ describe("TerminalView — where a dropped file lands", () => {
 
     expect(vi.mocked(uploadHostFileToTerminal)).not.toHaveBeenCalled();
     // A refused drop is otherwise indistinguishable from a broken one.
-    expect(
-      useAppState.getState().toasts.some((t) => t.message === "File drop ignored"),
-    ).toBe(true);
+    const notice = useAppState
+      .getState()
+      .toasts.find((t) => t.message === "File drop ignored");
+    expect(notice).toBeTruthy();
+    // Not an error: the user has a dialog open, which is a state they chose
+    // and can leave with Escape. An error card would sit there until
+    // dismissed, and `ToastHost` paints at `z-[60]`.
+    expect(notice?.kind).toBe("info");
 
     backdrop.remove();
     delete (document as Partial<Document>).elementFromPoint;
   });
+
+  it("keeps refusing when the refusal's own toast is painted over the dialog", async () => {
+    // C1, end to end. Refusing pushes a toast; `ToastHost` is `fixed
+    // bottom-4 right-4 z-[60]` and the `Modal` backdrop is `z-50` in the same
+    // stacking context — so the toast is the topmost element over the covered
+    // pane, and a gate that asked "is a blocker painted here?" answered no and
+    // uploaded into the directory the dialog was covering. The gate had armed
+    // its own hole: one refused drop was all it took to open it.
+    useAppState.setState({ toasts: [] });
+    await mountWithLayout();
+    const backdrop = document.createElement("div");
+    backdrop.setAttribute("data-blocks-drop", "true");
+    document.body.appendChild(backdrop);
+    stubElementFromPoint(backdrop);
+
+    await drop(400, 300);
+    expect(vi.mocked(uploadHostFileToTerminal)).not.toHaveBeenCalled();
+    expect(useAppState.getState().toasts).toHaveLength(1);
+
+    // The toast is now on screen, above the backdrop, and the user drops again
+    // on the very point it occupies.
+    const toastCard = document.createElement("div");
+    document.body.appendChild(toastCard);
+    stubElementFromPoint(toastCard);
+
+    await drop(700, 550);
+    expect(vi.mocked(uploadHostFileToTerminal)).not.toHaveBeenCalled();
+    // …and a second refusal replaces the first notice rather than stacking.
+    expect(useAppState.getState().toasts).toHaveLength(1);
+
+    toastCard.remove();
+    backdrop.remove();
+    delete (document as Partial<Document>).elementFromPoint;
+  });
 });
 
 describe("TerminalView — reaching the URL prompt without a mouse", () => {

app/src/components/terminal/TerminalView.tsx

@@ -21,7 +21,7 @@ import {
   parseUrlRelayOsc,
   sanitizeRelayUrl,
 } from "../../lib/urlRelay";
-import { classifyDrop } from "../../lib/dropTarget";
+import { classifyDrop, DROP_BLOCKED_TOAST } from "../../lib/dropTarget";
 import UrlToast, {
   URL_TOAST_PRIMARY_SELECTOR,
   URL_TOAST_SELECTOR,
@@ -236,23 +236,22 @@ export default function TerminalView({ sessionId, active }: Props) {
   // onDragDropEvent (HTML5 ondrop on the element wouldn't expose file paths).
   //
   // The listener is window-wide, so every pane decides for itself whether a
-  // drop was meant for it. `isDropTarget` is that decision, shared with the
-  // Files pane: the payload position against this pane's rect (a hidden pane is
-  // `display:none`, so its zero-size rect is what stops two panes both claiming
-  // the drop), plus z-order — which a rect alone cannot see. An open `Modal` is
-  // a `fixed inset-0` portal painted *over* the window and the pane underneath
-  // still has its rect, so the geometric test that used to live here uploaded
-  // files into the directory a dialog was covering. Same for the shutdown
-  // overlay, which is on screen precisely while nothing should be accepting
-  // work at all.
+  // drop was meant for it. `classifyDrop` is that decision, shared with the
+  // Files pane, and it asks two things in order: is the payload position
+  // inside this pane's rect (a hidden pane is `display:none`, so its zero-size
+  // rect is what stops two panes both claiming the drop), and — document-wide,
+  // with no geometry — is a modal or blocking overlay on screen at all? An
+  // open `Modal` is a `fixed inset-0` portal painted *over* the window and the
+  // pane underneath still has its rect, so a rect alone uploaded files into
+  // the directory a dialog was covering. See `lib/dropTarget.ts` for why the
+  // blocking half is deliberately not a per-point z-order test.
   //
   // The rect asked about is the **pane wrapper**, not the xterm host inside it:
   // the pane is what the user sees as "the terminal", gutter included, and the
   // chrome painted over it (the Following toggle, the URL toast) is a sibling
-  // of the host rather than a child. `classifyDrop` answers "is a *blocking
-  // overlay* here?" rather than "is this element mine?" for the same reason —
-  // asking the second question turned every pixel under that chrome into a
-  // permanent dead zone.
+  // of the host rather than a child. Nothing painted over the pane refuses a
+  // drop on its own account — asking "is this element mine?" once turned every
+  // pixel under that chrome into a permanent dead zone.
   useEffect(() => {
     let unlisten: (() => void) | undefined;
     let cancelled = false;
@@ -276,15 +275,10 @@ export default function TerminalView({ sessionId, active }: Props) {
         // sits above it.
         if (verdict === "blocked") {
           console.warn(
-            "[drop] refused: an overlay is covering the drop point",
+            "[drop] refused: a dialog or overlay is open",
             event.payload.position,
           );
-          useAppState.getState().pushToast({
-            kind: "info",
-            message: "File drop ignored",
-            detail:
-              "A dialog or full-window overlay is covering that point. Close it and drop the file again.",
-          });
+          useAppState.getState().pushToast(DROP_BLOCKED_TOAST);
           return;
         }
         if (verdict !== "accept") return;