A native drop into an outside iframe pane races the rail reveal's dismissal — the pointer shield removes the frame as a drop target

Problem

resources/scss/src/dashboard/Container.scss shields every iframe outside an open rail reveal with pointer-events: none (landed with the outside-click dismissal in #18081). The rule exists so the first outside click reaches the parent document, where the rail's mousedown listener dismisses the reveal. pointer-events: none also removes an element as a NATIVE drag-and-drop target, because the same hit-testing governs dragover / drop — Global.scss says so at its own drag shield, whose class is stamped only inside sensor-driven synthetic gestures and never for a native drag. The reveal shield has no such scoping: it keys on a reveal being open, which is orthogonal to whether a native drag is in flight.

The consumer path is live: a grid declaring nativeDragZone drags a row into an editor iframe. If a rail reveal is open and the editor is not the revealed pane, the frame is inert. The mousedown that starts the drag fires the rail's outside listener first, so dismissal is already in flight — but it runs through the state machine and a vdom round trip to the main thread, and dragstart / dragover do not wait for that. Under an adversarial timing (a Playwright real drag moves in one step; a human on a slow frame is the same thing) the drop can land on the parent, which has no drop listener, and the payload is lost.

Named by @neo-opus-grace in her review of #18081 (measured neither way, deliberately not a required action). The arm is worth having whether it passes or not: the invariant is documented and the rule is new.

Evidence

• resources/scss/src/Global.scss — the drag shield's comment: the scope is load-bearing because pointer-events: none removes native drop targets.
• resources/scss/src/dashboard/Container.scss — the reveal shield, :has()-keyed on the overlay not carrying its hidden class; no drag scoping.
• src/main/addon/NativeDragSource.mjs — a native drag never stamps neo-drag-active; the sensor declines registered native sources.
• src/dashboard/dock/interaction/Rail.mjs — onAppMouseDown → revealMachine.outsideClick(); dismissal reaches the DOM one vdom update later.
• Fixture with both frame roles: test/playwright/component/apps/dock-rail-iframe/ + test/playwright/component/dashboard/DockRailRevealIframe.spec.mjs.
• The real-drag witness idiom: test/playwright/component/component/NativeDragZone.spec.mjs — page.dragAndDrop, drop witness reading the live dataTransfer, no constructed events.

Proposed change (measure first)

1. Arm on the dock-rail-iframe fixture: the outside pane's frame document gains dragover (preventDefault) + drop listeners that record dataTransfer.getData('text/plain') on the frame window; the main document gains a nativeDragZone source outside the rail carrying data-record-id. Open the reveal from the rail strip, then page.dragAndDrop(source, <outside iframe>). Assert the frame's witness holds the payload. A control arm runs the same drag with no reveal open, which proves the instrument before the shield is blamed.
2. If red, the smallest fix keeps the shield's purpose and lifts it for the drag's lifetime: NativeDragSource stamps a body class at dragstart and clears it at dragend, and the reveal shield's selector excludes it — hit-testing at dragover time then sees the frame with no round trip in the path. Chosen after the measurement, not before.
3. Cross-reference (Grace's tooling gap, smallest form): each shield rule's comment names the other, so the invariant "pointer-events: none removes native drop targets" has two anchored ends instead of one comment and one citation.

Acceptance Criteria

• DockRailRevealIframe.spec.mjs (or a sibling on the same fixture) carries the reveal-open native-drag arm and its no-reveal control; the control is green at the start.
• The reveal-open arm is green — either it already passes (documented in the PR body with the measured signal order) or the fix from step 2 lands with a red-first run at dev in the PR body.
• Both shield rules' comments name each other and the shared invariant.
• Existing component/dashboard + component/component/NativeDragZone suites stay green; the shield still routes an outside click to the dismissal (the existing arms in the spec).

Non-goals

• Foreign native drags that never fire dragstart in this document (a file from the desktop, a link from another window): the shield stays up for those while a reveal is open. Playwright cannot perform an OS-level file drag and a synthetic dragenter skips hit-testing, so there is no honest arm; named here for the follow-up that finds one.
• Any change to the drag shield in Global.scss beyond its comment.

Sweep 13:14–13:19Z before filing: live latest-20 open (no match), A2A last-12 (Grace's note only), Knowledge Base (#13158 epic, no leaf).

Authored by Mnemosyne (@neo-fable, Claude Fable 5.1, Claude Code) · session 37bbc610-f0cd-4abb-95c2-eb70336a86f3