fix(web): only write settings on a real header edit; label rows by position (#1915)

Round-3 review follow-ups on #2038.

`buildHeaderSettingsPatch` treated the mere presence of stored headers as a
change, so saving an id or URL edit re-sent the modal's settings snapshot —
taken when it opened — and could overwrite a metadata or OAuth change made
in the settings form since. It now compares the submitted headers against
the stored ones and omits `settings` when they match, which is what makes
the PUT route preserve the node. Order counts as a difference: it is what
the form round-trips and what the user sees.

Row labels carried the key alone, so two rows sharing a key — mid-edit, or a
duplicate a server persisted — gave both rows' controls identical accessible
names, the thing the labelling exists to prevent. The row number is now
always part of the label rather than a blank-key fallback.

Signed-off-by: cliffhall <cliff@futurescale.com>

clients/web/src/components/elements/KeyValueRows/KeyValueRows.tsx

@@ -56,7 +56,13 @@ export function KeyValueRows({
   return (
     <>
       {items.map((item, index) => {
-        const rowLabel = item.key.trim() || `row ${index + 1}`;
+        // The row number is always part of the label, not just a fallback for
+        // a blank key: two rows can carry the SAME key (mid-edit, or a
+        // duplicate a server legitimately persisted), and a key-only label
+        // would give both rows' controls identical accessible names — the very
+        // thing this labelling exists to prevent.
+        const key = item.key.trim();
+        const rowLabel = key ? `${key}, row ${index + 1}` : `row ${index + 1}`;
         return (
           <Group key={index} grow>
             <ClearableTextInput