Keep element state when the runtime moves a node (`moveBefore()` and not detaching what is re-inserted)

Start by reading the keyed reconcile and insert paths, then trace the swap path that uses replaceChild and how removals are ordered against inserts when nodes migrate between parents. Benchmark moveBefore() against insertBefore on those hot paths and measure the cost of deferring removals; performance is the decision gate. Done means deciding the scope and fallback behavior, then validating the behavior and performance against the stated acceptance scenario.

Summary

When a DOM node changes position, @solidjs/web moves it with
insertBefore / replaceChild, and in some cases removes it first and
inserts it afterwards. The browser treats each of these as a removal and an
insertion, so state that lives on the element's connection to the document is
reset: focus, CSS animations and transitions, iframes (they reload), popover
and fullscreen state, and so on.

Element.moveBefore() moves a connected node without that reset. Adopting it
would let Solid 2.0's "one element, several positions" behaviour keep that
state too. This issue is to track it. It needs performance vetting before
any decision.

Where it shows up

• Keyed lists. A focused row that is reordered loses focus.
• An element referenced from more than one position (the
  migrating-element example; a card created once and referenced from
  whichever list holds it). The node keeps its identity, listeners, value and
  selection, but loses focus, and an <iframe> or a running CSS animation
  would restart.
• In an app this reads as: an editor that stays open with its draft intact
  but has to be clicked again after someone else moves its card, and a
  keyboard "move this item" shortcut that works once and then has nothing
  focused.

What was measured

Chromium 152, dev build, origin/next at 2322d6407. One board-level
mapArray creates each card element; three lists' <For>s reference the
elements of the cards they hold; a store write moves a card. DOM calls on the
card element were logged by patching the prototypes.

With a focused <input> inside the moved element:

A raw-DOM baseline agrees: moveBefore() on a focused input keeps focus, and
appendChild loses it.

So there are two separate parts:

1. Use moveBefore() when the node being inserted is connected (same
   document, and the other preconditions the method has).
2. Do not detach a node that the same flush re-inserts. Today about half
   of the moves above detach first, and no move API can help a node that is
   already disconnected when it is inserted.

Part 2 is the larger change. It touches the reconcile's swap path
(replaceChild then re-insert) and the ordering of one position's removal
against another position's insert when a node migrates between parents.

Open questions

• Performance. moveBefore() on the hot paths (keyed reconcile, the
  insert path) against insertBefore, in the usual benchmarks, plus the cost
  of the feature check and of any deferral of removals for part 2. This is
  the gate.
• Support. Not in every browser yet (Chromium and Firefox have it,
  Safari does not, as far as we know at the time of writing; versions to be
  confirmed against MDN). Feature-detect and fall back; a browser without it
  behaves as today.
• Preconditions. moveBefore() throws where insertBefore does not (a
  disconnected node, a different document, some shadow-root cases). Each
  call site needs the check or a fallback.
• Custom elements. With moveBefore() an element gets
  connectedMoveCallback if it defines one; otherwise the disconnected and
  connected callbacks still run. Worth stating in the docs.
• Scope. Reorders within one parent only, or migration between parents as
  well (which is where part 2 matters most).
• Semantics to document. What survives a move today (identity,
  listeners, value, selection, canvas bitmap) and what would be added (focus,
  animations, iframes, popover and fullscreen state).

Not measured

Firefox and Safari. <iframe>, <video>, CSS animations and popovers (the
migrating-element README's open question about media). Focus was set from
script, and moveBefore() was simulated by patching insertBefore in the
page, not by changing the runtime.

Acceptance test this would unblock

In a board example that is in progress: open a card's title editor in one tab and type half a
word; move that card to another list from a second tab. Today the editor
stays open with the draft and selection intact, and focus is gone. With this
work the next keystroke lands in the editor. The example also carries a
one-line refocus after keyboard moves that could then be deleted.