Et2Nextmatch: stop CustomfieldsHeader's endless update loop when all customfield columns are hidden

[asig2016]

Symptom: the browser tab hard-freezes (renderer unresponsive, must be killed) as soon as anything re-applies column preferences on a nextmatch whose app has custom fields defined while the user has every customfield column hidden — e.g. applying a filter. There is no stack overflow and no console output, which makes it very hard to diagnose: profiling probes on promises, timers, rAF and events all come back clean; only wrapping Lit's performUpdate reveals the loop.

Cause: the datagrid's column-preferences pass hands Et2CustomfieldsHeader an explicit empty fields map ("all hidden"). updated() treats the empty map as "not yet hydrated" and calls _syncCustomfieldsFromModifications(), which reports changed and reassigns this.fields = {...previousFields} — a fresh but content-identical object. Lit's default hasChanged is !==, so every update schedules the next one, forever.

Fix:

• don't reassign fields when explicit visibility is preserved anyway (no fresh clone → no phantom property change),
• treat an explicit empty allow-list as a legitimate state, not as missing data needing re-sync.

Verified live against a production instance exhibiting the freeze (patching the deployed class the same way stops the loop; the filter applies normally). Et2Nextmatch test suite passes (149/149), including CustomfieldsHeader.test.ts.

🤖 Generated with Claude Code

[nathangray]

I'm not sure how you can tell the difference here between all customfields turned off and first time loading, when there is no preference. If it's the first time / no preference, no fields selected should mean all fields selected.
A better place to deal with this might be when the preference is applied and we know there is a preference, or when preference is saved - if there's no customfields selected, hide the whole column too.