fix(csvim): bind the UPDATE's WHERE key at the table's column count

[delchev]

Fixes #6676.

CsvProcessor.updateCsvWithHeader bound the UPDATE's WHERE <pk> = ? parameter at the CSV record's field count M instead of the table's column count N. The statement carries N−1 SET placeholders plus the WHERE at N, so the two agree only when the CSV is exactly as wide as its table.

• M < N — the id lands in SET slot #M and the real WHERE placeholder is never set. H2's checkParameters throws before execution, so it fails closed: no corruption, but no corrected seed value can ever reach an existing row.
• M > N — parameter index out of range.

INSERT binds by column name and is unaffected, which is why only re-imports broke. It stayed invisible because a plain nomenclature seed (id,name over a two-column table) is exactly as wide as its table by construction; any table with columns the CSV does not carry — most commonly the four audit columns — misses by that many.

The two positional siblings from the issue

Both had the same assumption, and both are fixed here:

• updateCsvWithoutHeader bound SET slots for the record's fields only and the key at M, leaving the trailing SET slots and the WHERE unbound for a narrow record.
• insertCsvWithoutHeader bound M placeholders while insert() builds N.

They now iterate the table's columns and bind a column the record does not reach as null — the outcome the header path already produces for a column the CSV omits, so the two paths agree rather than diverging on the same file. The semantic call the issue asked for is therefore bind null, not reject, on the narrow side. A record with more fields than the table has columns has nowhere to put them: that now fails with a message naming the counts and the table, instead of an IndexOutOfBoundsException, because silently dropping trailing fields would import a row that does not say what the file says.

One more cause found while testing

update() resolved the skipped SET column and the WHERE column separately. getPkName returns null for a headerless CSV (it only looks up the key column when header names are present), and getName().equals(null) is false — so nothing was skipped, the statement grew to N+1 placeholders, and no binder could satisfy it. The headerless IT caught this as Parameter "#4" is not set on a 3-column table. One resolved name now drives both the skip and the WHERE, making the statement shape invariant.

Tests

CsvimReimportIT (new, untagged so it runs in the PR smoke gate) asserts at the outermost layer per the issue's request: import, change a value, re-import, then assert the row holds the new value and that a column the CSV does not carry is null rather than the record's id. Both fixtures are deliberately narrower than their table — an M == N fixture passes with the arithmetic still wrong.

Verified red before, green after: with the fix reverted, Tests run: 2, Failures: 2; with it, Tests run: 2, Failures: 0. Neighbouring suites re-run green: CsvimIdentityRestartIT, CsvimIT. Formatter and release-profile javadoc clean on both changed modules.

Note for maintainers, not addressed here

The existing CsvProcessorTest in tests/tests-integrations/src/main/java never runs: failsafe is configured with testClassesDirectory=${project.build.outputDirectory} and **/*IT.java, while surefire has no such override, so a *Test class in that module's src/main/java is compiled and then skipped by both. That is why the new coverage is an IT rather than an addition to that class. Worth a separate look — there may be other dead *Test classes in there.