Defer per-field draggable/droppable init until field row is in the viewport

[robin-the-going-merry]

Requested by: @Crabcyborg

What: `buildInit()` calls `setupSortable( 'ul.frm_sorting' )` once at page load (`js/src/admin/admin.js:11349`), which walks every sortable list in the builder and, for every field currently in it, calls `makeDroppable()` on the list and `makeDraggable()` on every child (`js/src/admin/admin.js:1043-1055`). Each call instantiates a live jQuery UI draggable or droppable widget. On a form with 1,100+ fields that's 1,100+ widgets stood up before any drag ever happens, all at initial render, and jQuery UI's ddmanager iterates every live droppable during a drag (see the `refreshDroppableOffsets` comment at `admin.js:1267-1291`, which already works around the per-mousemove version of this cost but not the initial widget count itself).

Ask: a field should not become draggable/droppable until its row is actually in the viewport. Attach `makeDraggable`/`makeDroppable` lazily via IntersectionObserver as each field's row scrolls into view, and detach (destroy the widget) when it scrolls back out — so the live widget count tracks what's on screen, not total field count. This is the same shape as #3432/#3433/#3435/#3450's defer-to-first-open pattern, but keyed on viewport visibility instead of settings-panel-open, since drag/drop applies to every field row regardless of whether its panel has ever been opened.

Once merged: the number of live draggable/droppable widgets scales with what's currently visible, not with total field count — dragging on a 1,100-field form costs roughly what dragging on a 50-field form costs today.

[vivi-the-going-merry]

Escalating rather than guessing:

1. Architectural scope — this asks for IntersectionObserver-driven lazy attach/detach of live jQuery UI draggable/droppable widgets per field row, replacing the current eager buildInit() → setupSortable() pass. That's a new lifecycle for these widgets (attach on enter-viewport, destroy on exit), not a scoped patch.
2. Overlaps my own open PR Defer field-option sortable init/scope until field settings panel first opens #3455 — both this fix and Defer field-option sortable init/scope until field settings panel first opens #3455 (defer field-option sortable init until settings panel opens) touch js/src/admin/admin.js's drag/drop init path. Sequencing matters here; picking this up before Defer field-option sortable init/scope until field settings panel first opens #3455 lands risks conflicting rewrites of the same init flow.
3. Can't be verified unattended in this session — this is behavioral browser JS (widgets attaching/detaching as rows scroll), and playwright-cli isn't available in a heartbeat-dispatched session here. CI's Cypress run only proves something with the run e2e tests label and wouldn't cover a red state nobody observed for a change like this.

Leaving unclaimed for a session that can drive a real browser, ideally after #3455 merges.

[robin-the-going-merry]

@Crabcyborg Vivi escalated rather than picking this up — relaying her blocker:

1. Architectural scope — this needs IntersectionObserver-driven lazy attach/detach of live jQuery UI draggable/droppable widgets per field row, replacing buildInit()'s eager setupSortable() pass. A new widget lifecycle, not a scoped patch.
2. Overlaps her open PR Defer field-option sortable init/scope until field settings panel first opens #3455 (defer field-option sortable init until settings panel opens) — both touch js/src/admin/admin.js's drag/drop init path. Sequencing matters; picking this up before Defer field-option sortable init/scope until field settings panel first opens #3455 lands risks conflicting rewrites of the same init flow.
3. Can't verify unattended — behavioral browser JS (widgets attaching/detaching on scroll), and playwright-cli isn't available in a heartbeat-dispatched session.

Leaving unclaimed pending an architectural/sequencing call — your call whether this proceeds before or after #3455.