A committed tear-out re-renders its pane instead of moving the node out of the provisional chrome

Context

#17844's census lists WorkstationHumanPopupOverlapNL › pointer tear-out commits the same pane into its full PopupWorkspace (#18409) red at dev a9abb6c1dc and at 08a84ef3be:

the same DOM node moves with its pane
Expected: true   Received: false        (WorkstationHumanPopupOverlapNL.spec.mjs:713)

Bisected on the unmodified spec file (headless, --workers=1): 2 passed at 4dc6f744e5, red from bc70dfbf72 (#19212, Resolves #19210). The poll just before the failing line still passes: one element carries the pane id, its parent is the committed card body, and the worker parent matches. The node is re-created, not duplicated (#18409's original defect).

The Problem

The spec takes the pane's element in the popup while the vessel is staged (:667) and asserts that the same node is connected after the terminal (:713). Since #19212 the staged pane lives in a provisional DockTabContainer. At the terminal the committed projection mounts in its place through VesselWorkspace#retireProvisionalVesselChrome(windowId, {releasePanes: true}) (#19214):

• body.remove(pane, false, true) detaches the pane silently, so no DOM move is emitted;
• the chrome is then removed with destroy, and its DOM subtree still holds the pane's node;
• the committed projection re-parents the pane "by identity" (the method's docblock), which renders a new node.

The pane instance survives, but its DOM node does not. For a pane holding an iframe, a canvas, media or a scroll position, the commit reloads or resets it. That is the object-permanence contract #18409 pinned, and it shows at the one moment the operator is watching: the drop.

The Architectural Reality

• The pre-#19212 path moved the node: 2 passed at 4dc6f744e5.
• Dock re-projection elsewhere keeps live panes by moving their nodes (the projection's reconciler stages its child; DockPreview and DockDropIndicators stay persistent siblings, Workspace.mjs). The provisional chrome is the one handover that releases detached.

The Fix

Direction for the owner: hand the pane from the provisional chrome's body to the committed card body as a move, one non-silent reparent that emits a node move, before the chrome is destroyed. Do not re-render it after the chrome's subtree is gone. The exact seam is the owner's call (#19214 chose the release-then-adopt order).

Acceptance Criteria

• AC-1: WorkstationHumanPopupOverlapNL passes at the head (headless, --workers=1, runtime root bound).
• AC-2: the provisional chrome still shows the staged pane from the first frame (#19210's AC stays met; its witnesses stay green).
• AC-3: a unit arm pins the handover: the pane's node before the terminal is the node after it.

Out of Scope

• #19186 (the park's z-order under a real drag).
• The census, refreshed on #17844.

Related

#17844 (census) · #18409 (same pane, no duplicate) · #19210 / #19212 / #19214 (the provisional chrome) · #19250 / #19251 (its compact header)

Origin Session ID: 81d1894c-d8fd-4192-8350-42e32eb0101e Retrieval Hint: "tear-out commit re-renders pane DOM provisional chrome retireProvisionalVesselChrome releasePanes same DOM node #18409"