Route browser-pane file drops by intent so they never silently become previews - #7634

… previews

A file URL dragged over a workspace browser pane's page content was routed to
the hosted WKWebView only when the webview was resolvable at that instant:
resolvedFileDropBehavior's `guard canDropAsText else { return .preview }`
silently converted the drop into a cmux file-preview whenever
hostedWebViewForFileDrop(at:) returned nil — a legitimately transient state
(webview discarded by BrowserHiddenWebViewDiscardManager, mid-reparent through
the browser window portal, stale frame). shouldCaptureHitTesting additionally
computed the behavior with a hardcoded `canDropAsText: true`, so the pane
could claim a drop as an upload during hit-testing and execute it as a
preview.

Fix the class, not the symptom: introduce BrowserPaneFileDropRouting, a pure
disposition seam (pasteboard payload, modifier flags, dock-hosted flag,
file-drop default setting) with no webview-availability input. Hit-testing,
update, prepare, and perform all branch on the same seam, eliminating the
claim/perform divergence, and the existing Dock rule (file URL over Dock page
content always forwards to the page) is centralized there.

Webview availability is now purely a delivery concern: delivery falls back
from the slot lookup to a same-pane BrowserWindowPortalRegistry lookup, a
discarded webview is asked to restore once per drag session while hovering,
and if no webview resolves the drop is refused (prepare/perform return false)
— never reinterpreted as a preview. Shift inversion, preview-default routing,
pane-edge split zones, Dock live-surface transfers, tab drags, and cmux
file-explorer preview transfers keep their existing paths.

Closes #7632

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

shouldCaptureHitTesting ran AppDelegate.dockForPane (an all-windows x
workspaces x docks ownership sweep) as an eagerly evaluated argument on
every hitTest call, and allowsPaneDropHitTesting admits pointer-hover
events, so mouse moves over a browser pane paid for the sweep. The value
cannot change the capture result: a file-URL payload yields a disposition
either way (shouldCaptureFileDrop true), and without a file URL the
disposition is nil either way. Drop the parameter and hit-test with
isDockHosted: false; prepare/perform still resolve the real dock-aware
disposition.

Also make disposition's isDockHosted an autoclosure evaluated only after
the file-URL guard, so drag callbacks for non-file payloads (tab drags,
preview transfers) no longer pay for the dock sweep either, and add a
regression test pinning the laziness contract.

Found by structured review on PR #7634.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Repo testing policy requires Swift Testing for new non-UI test files:
convert BrowserPaneFileDropUploadRegressionTests from XCTestCase to a
@mainactor @suite(.serialized) struct (serialized because the drag
lifecycle tests flow the file-drop default through the production
UserDefaults.standard read, matching LastSurfaceClosePreferenceTests).
Assertions map 1:1; the harness classes are unchanged.

Also nest the two-case Disposition result enum inside
BrowserPaneFileDropRouting, its only producer, tightening the file to a
single top-level type.

Found by structured review on PR #7634.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…page

A file drag over browser page content now always forwards to the hosted
WKWebView (Safari/Chrome-style page delivery) regardless of the
fileDrop.defaultBehavior setting, which continues to govern terminals
and editors. Shift is the explicit cmux gesture: it skips the page and
opens the file-preview/split flow directly.

When the page does not consume a forwarded drop, WebKit falls back to
navigating the main frame to the dropped file:// URL, destroying the
page (confirmed in the field: performAsWebView handled=1 followed 49ms
later by a main-frame .other file:// navigation). Every WKWebView
file-drop delivery now records into BrowserFileDropNavigationGuard
(weak webview identity, 5s TTL, consume-once), and
BrowserNavigationDelegate cancels a matching main-frame .other file://
navigation, opening the file in a cmux preview split beside the browser
pane instead. Unmatched file:// navigations (omnibar, links,
back/forward, Dock and popup webviews) fall through natively.

WKWebView.cmuxRunPrintOperation and the interactive-modal host-window
fallback are extracted verbatim into satellite files to keep
BrowserNavigationDelegate.swift and BrowserPanel.swift within their
file-length budgets.

Closes #7632

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

An automated real-drag repro (probe page with capture-phase listeners
preventDefaulting every drag event) showed the DOM never receives drop:
it sees dragenter, dragover, then dragleave at drop time. The window
file-drop overlay's prepare/perform routes called exitActiveDragTargets
before delegating to the same pane target, and the pane's draggingExited
forwards webView.draggingExited — cancelling WebKit's drag session, so
the following performDragOperation had no live session, the page could
not receive the drop, and WebKit ran its navigate-to-file fallback. This
was the root cause of uploads intermittently degrading ever since the
overlay hand-off existed.

Exits are now selective: a target chosen for prepare/perform/conclude of
the current drag never receives draggingExited mid-session; targets the
drag genuinely left, the real draggingExited path, and the capture-miss
cleanup branches still exit everything.

Also arm BrowserFileDropNavigationGuard only for handled drops (review
feedback): a rejected delivery no longer records paths that a later
unrelated file:// navigation could match within the TTL.

Verified end-to-end with the scripted Finder drag: the probe page now
receives the DOM drop (dragenter/dragover/drop), and dogfood confirms
page uploads (Vanta .pdf policy upload) work.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>