fix(csvim): change detection spans the referenced CSV files (#6686)

[delchev]

Fixes #6686 — the sequel to #6676 / #6683: that one fixed the UPDATE binding so a re-import can apply a changed value; this one makes the re-import actually trigger when only a referenced .csv changes.

The defect

SynchronizationProcessor.checkAndCollect computed the definition checksum from the .csvim file's own bytes alone. The referenced CSVs were opened only inside importCsvim, well after the MODIFIED decision — so editing only a CSV left the artefact CREATED, both inner switches fell through, and nothing was imported. No error, no warning. Since the .csvim is a stable pointer that stays byte-identical when a seed value changes, the ordinary editing path could never reach the re-import.

The fix

• Synchronizer.checksumContent(location, content) — a new default hook returning the content whose checksum decides whether the definition is MODIFIED. Default: the file's own bytes (no behavior change for any other synchronizer).
• SynchronizationProcessor.checkAndCollect calls the hook and, when it extends the content, updates the definition checksum with the extended bytes. The definition's content (what parse receives) stays the .csvim's own bytes.
• CsvimSynchronizer overrides the hook to append each referenced CSV's content to the .csvim bytes, so an edited CSV yields MODIFIED and the existing UPDATE path runs unchanged (which, with fix(csvim): bind the UPDATE's WHERE key at the table's column count #6683 merged, now applies values correctly). A CSV that does not exist yet contributes nothing — its later appearance changes the checksum and triggers the import, closing a second silent gap for free. A parse failure falls back to the original bytes (the definition then breaks in parse as before).

Test

CsvimReimportIT.editingOnlyTheCsvTriggersReimport drives the full synchronizer path: writes .table + .csv + .csvim registry fixtures, forces a sync, then rewrites only the CSV (the .csvim stays byte-identical — per the issue's warning, a fixture that also touches the .csvim passes while missing the bug) and asserts the row's value after the second sync.

• Verified red on unfixed code: expected: <Varna> but was: <Sofia>
• Green with the fix; the two pre-existing CsvimReimportIT tests stay green
• Unit tests of the three touched modules green; formatter:validate and the release-profile javadoc check pass

Not touched (deliberately)

The switch (flow) fall-through in CsvimSynchronizer.completeImpl that the issue flags under "worth the implementer's attention" is left as-is — this fix rides the existing UPDATE/MODIFIED path and does not depend on the fall-through's behavior; changing lifecycle-transition semantics is out of scope here.

🤖 Generated with Claude Code