fix: prevent custom columns from resetting to defaults when saving preset or renaming column

[ausias-armesto]

Problem

close #5657
Users on custom (non-static) presets would see their column layout silently reset to the default columns in two scenarios:

Bug 1: Renaming a column or changing its format wiped all other column config

updateMultipleColumnConfigs built a partial object containing only the fields passed in the call (e.g. just column_rename_mapping). The backend PUT /preset/{id}/column-config treats the body as a full replacement, so sending only one field erased column_visibility, column_order, and every other field. Any column the user had added that wasn't in the default set would then disappear.

Fix:
updateMultipleColumnConfigs now always sends the full current config to the backend, using the incoming updates to override only the changed fields (?? operator). This ensures a rename, format change, or visibility toggle never erases unrelated config fields.

Bug 2: Saving the preset itself reset the column layout

mutatePresetsList called revalidateMultiple(["/preset", "/preset?"]) using the default prefix matching (key.startsWith(k)). This accidentally matched /preset/{id}/column-config in the SWR cache, triggering a re-fetch and discarding the cached column config. Since the column config is stored and fetched separately from the preset list, it should never be invalidated by a preset save.

Fix:
usePresetActions — mutatePresetsList now uses isExact: true for the /preset key and prefix matching only for /preset? (query-string variants). This correctly invalidates the preset list without touching /preset/{id}/column-config.

usePresetColumnConfig — Removed the redundant revalidateMultiple(["/preset", "/preset?"]) call after saving column config. The hook's own mutate() already revalidates /preset/{presetId}/column-config; the extra call was unnecessary and subject to the same prefix-matching collateral damage.

[CLAassistant]

All committers have signed the CLA.

[shahargl]

lgtm