DockSplitter drag-start wedges intermittently: pointerdown lands, drag never starts

Context

Surfaced during the #16353 grid-freeze investigation (full arc: issuecomment-5158564279). The DockSplitter drag-start wedges intermittently at dev head — and the wedge, not a repaint stall, is the defect most consistent with the operator's observed "grid freezes at some point": when the drag-start dies, the layout freezes by definition and every drag-derived update path stalls, leaving a live-Store grid that looks frozen.

The Problem

Across fresh boots, on BOTH event origins (raw CDP page.mouse AND the app-side InteractionService real-pointer dispatch — the film's own event class), a pointer drag on the projected horizontal DockSplitter never starts:

• document.elementFromPoint at the hit point returns the splitter itself (DIV.neo-dashboard-dock-splitter.neo-dashboard-dock-splitter-horizontal.neo-draggable) — the pointerdown lands on the right element
• a document-level capture probe records pointerdown + mousedown firing on the splitter
• dragStartState on every Neo.dashboard.DockSplitter instance stays false — the chain between DOM pointerdown and the app-side DragZone start never fires
• resizeSplit never commits (document sizes unchanged after the full gesture)

Time window at head 5703e0d18f (this host): 10/10 consecutive drags committed at 13:52Z; 0/10 from ~14:05Z, still wedged ~40 min later. Headless shows the identical wedge (not window contention). Tab drags keep working through it (WorkstationFiveBeatNL scene 2 tear-out green at 14:2xZ) — the wedge is specific to the DockSplitter drag family, not the pointer pipeline.

The Architectural Reality

• Chain: DOM pointerdown on .neo-draggable → main-thread DomEvents delegation → app-side draggable manager → DragZone.dragStart() → 'drag:start' → DockSplitter.onDragStart (src/dashboard/DockSplitter.mjs:328) → dragStartState set → moves → onDragEnd → commitResizeSplit
• The wedge sits between the DOM event (confirmed firing) and DragZone.dragStart() (confirmed not running) — i.e., the DomEvents delegation or the manager's dragZone resolution for .neo-draggable
• Tab drags ride a different family (tab-header sort/tear-out machinery) and stay healthy — the wedge discriminates at the drag-family level, not the addon level
• Prior art: #14985 (closed) repaired a stale-DOM geometry family — related thematically, unproven as the same cause; the wedge's time-variance (green → wedged within 15 minutes across fresh boots) needs its own bisect

The Fix

1. Reproduce in the wedged state with a document-level probe at each chain segment (DomEvents delegate registration present? dragZone resolved? manager handler invoked?) and name the dead segment.
2. Bisect the 13:52→14:05 window on this host (candidate axes: a peer app on the shared bridge, host window-manager state, a time-based listener teardown).
3. Repair the owning segment; WorkstationGridRepaintNL.spec.mjs (authored, currently red only through the wedge) is the natural regression witness.

Acceptance Criteria

• The dead chain segment is named with a per-segment probe receipt (not inferred)
• The trigger condition (time window / host state / peer interaction) is falsifier-bound
• DockSplitter drags commit across 10 consecutive cycles via the InteractionService path AND the CDP path (the witness in #16353's investigation branch goes green)
• Tab-drag and DockSplitter-drag families both green in the same session

Out of Scope

• The repaint truths themselves (exonerated where drags commit — #16353 receipt)
• Text selection during drags (#16362 — separate surface, though the wedge's missed drags may share a hit-target boundary with it)
• Preview-surface witnesses (#16341)

Related

• #16353 (parent investigation + receipts) · #16362 · #16341 · closed prior-art #14985

Origin Session ID: 1a7e3f91-8356-48bb-a353-9fd7da2647f5

Retrieval Hint: "DockSplitter dragStartState never activates pointerdown lands DomEvents neo-draggable delegation wedge"