perf(tree-view-table-layout): PATCH only the rows that actually changed on drag-save

[seltzdesign]

Problem

Every drag (reorder or reparent) saves by PATCHing every edited row, even when a row's payload is identical to what is already in the database. On a moderately sized tree this is hundreds of redundant write requests per drag. Two real consequences:

1. Slow saves — the save fans out into 600+ sequential PATCHes on a large collection, most of them no-ops that still cost a round trip.
2. A reload race — because all those writes are queued sequentially and a reparent can sit at the back of the queue, a fast user reload can land before the meaningful write (the new parent) has been persisted, so the reparent appears to be lost.

Root cause

saveEdits in src/index.ts loops over Object.entries(edits) and unconditionally PATCHes each row's full payload. There is no comparison against the current value, so unchanged sort keys are written back identically, and there is no ordering, so a structural change (parent) has no priority over bulk sort-position updates.

Fix

In saveEdits:

• Diff each field against the current item (items.value) and build a changed payload containing only fields whose value actually differs. M2O values are normalised before comparison via a small relKey helper (handles the { [pk]: ... } object form, the scalar-key form, and null) so an unchanged parent expressed in a different shape is not treated as a change. Rows with no real change are skipped entirely (no PATCH).
• Send parent edits first. Entries are sorted so rows whose payload includes the parent field are PATCHed before pure sort-position rows. This persists a reparent immediately, ahead of the now-minimal set of sort updates, closing the reload race.
• New rows (no matching original) still send their full payload, since there is nothing to diff against.

Verification

• Reordering two siblings now issues only the PATCHes for the rows that moved, instead of re-writing the whole collection's sort key.
• Reparenting a node persists the parent change first; a fast reload immediately after the drag keeps the new parent.
• A drag that results in no net change produces zero PATCH requests.
• Confirmed unchanged M2O parent values (object vs scalar representation) are correctly treated as unchanged and not re-sent.

No change to the on-disk result of a save — only which requests are sent, and in what order.