fix: resolve header cells against the built-in read converters (#1098)

[Mikkey-f]

Fixes #1098

What changes were proposed in this pull request?

ConverterUtils.convertToStringMap turns header cells into strings for two consumers: the name matching in DefaultAnalysisEventProcessor.buildHead and the map handed to AnalysisEventListener.invokeHeadMap. It resolved the converter through the holder's converter map, which also carries user registrations — so a user-registered Converter<String> was applied to the header text itself: the header flag became FLAG, @ExcelProperty("flag") no longer matched, and the field was left null with no exception. The data cell was not converted either.

The lookup now uses the built-in read converters (DefaultConverterLoader.loadDefaultReadConverter()) only. Data cells are still resolved with user converters through convertToJavaObject; the write path is untouched.

Why

• The header path exists to produce the raw header text used for name matching; converters are for data cells. This is the direction agreed in [Bug] Header cells are converted with user-registered String converters, breaking @ExcelProperty(name) matching #1098.
• An explicit (String, STRING) registration reproduces the failure on current main; a wildcard Converter<String> would reach the same path once feat: honor wildcard custom converters when reading #1086 expands wildcard registrations on read.
• The built-in read table covers every cell type that can reach this path — STRING, NUMBER, BOOLEAN and ERROR (the v07 handler normalises DIRECT_STRING and ERROR to STRING; v03 keeps ERROR; DATE and RICH_TEXT_STRING are not produced on read) — so no cell type loses conversion. A type without a built-in converter still reports the existing Converter not found error.

Impact

• Header text is no longer rewritten by user converters, so name matching is stable again.
• invokeHeadMap now receives the raw header map — the behaviour change settled in [Bug] Header cells are converted with user-registered String converters, breaking @ExcelProperty(name) matching #1098 ("the header should stay raw text").
• A wildcard Converter<String> is covered as well; this is the case feat: honor wildcard custom converters when reading #1086 would otherwise widen into the header path.
• Data cells are unchanged; field-level converters (@ExcelProperty(converter = ...)) and the write path are untouched.

How was this patch tested?

New HeaderConverterIsolationTest (3 tests):

• explicit STRING-key converter: name matching still works and the data cell is converted (red before the fix: the field was null);
• invokeHeadMap receives the raw header text (red before the fix: FLAG instead of flag);
• wildcard converter: the header stays raw and name matching keeps working.

ConverterUtilsTest is updated to the new contract: the convertToStringMap tests now assert that a user registration in the holder's map is not consulted (the mock converter is never invoked), and the missing-converter case uses DATE, which genuinely has no built-in (String, DATE) converter (BOOLEAN does, so it no longer exercised that path).

Red/green verified: both failing cases were reproduced against the pre-fix code, then turned green. Full suite: 1047/1047 green; spotless and javadoc pass.

Notes

• refactor: decouple read/write responsibilities and introduce ColumnBinding #1128 rewrites the same lookup in ConverterUtils; whichever lands second needs a trivial rebase of this one line.