fix(sheet): escape hex sequences in head and multi-variable fill cells

[Sean-Walker0]

Purpose of the pull request

The default EscapeHexCellWriteHandler only sees cells that pass through the converter flow (afterCellDataConverted), so two XLSX write paths stored literal _xHHHH_ sequences unescaped, and POI's reader decoded them into the characters they name:

• head cells: WriteContextImpl.addOneRowOfHeadDataToExcel wrote the head string via setCellValue directly — a head "_x0041_ col" round-tripped as "A col";
• multi-variable fill cells: ExcelWriteFillExecutor converted each variable value but assembled the surrounding template text itself and stored the joined string directly — filling p {a} s with a = "_x0041_ x" round-tripped as "p A x s".

This closes the coverage gap disclosed in the Notes of #1223 (data cells, streaming and in-memory, are covered there).

What's changed?

• The escape scanner moves from the handler into XlsxEscapeUtils.escape(String) — the write half of the existing utfDecode — and the handler delegates to it (single implementation for both directions, as the class javadoc already documents).
• WriteContextImpl applies XlsxEscapeUtils.escape to head strings for XLSX writes.
• ExcelWriteFillExecutor applies it to the joined multi-variable fill string for XLSX writes (the variable values there never pass through afterCellDataConverted, so nothing is pre-escaped and double-escaping cannot occur).
• Both paths stay outside the handler event flow on purpose: firing afterCellDataConverted for heads breaks the documented CellWriteHandler call matrix that WriteHandlerTest pins (19/23 of its cases fail with the hook variant). Escaping stays a property of the default handler set for XLSX, now applied wherever text reaches a cell.

Checklist

• I have read the Contributor Guide.
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

Verifying this change

EscapeHexHeadAndFillWriteTest (default handler registration, both red before, green after):

• headCellRoundTripsLiteralEscapeSequences — expected: <_x0041_ col> but was: <A col> before;

• fillMultiVariableCellRoundTripsLiteralEscapeSequences — expected: <p _x0041_ x s> but was: <p A x s> before.

• All existing escape suites pass unmodified (EscapeHexCellWriteHandlerTest 19, EscapeHexCellWriteHandlerRoundTripTest 4, EscapeHexInMemoryWriteTest 2) and WriteHandlerTest 23/23 confirms the handler call matrix is unchanged.

• ./mvnw clean package -B -Dmaven.test.skip=false -pl fesod-common,fesod-shaded,fesod-sheet: 1049 tests, 0 failures, 0 errors.

• ./mvnw -pl fesod-sheet spotless:check: clean.

Notes

• Behavior change: head and multi-variable fill strings on XLSX writes that contain _xHHHH_-shaped text are now preserved literally instead of being decoded by the reader. XLS and CSV writes are untouched (no _xHHHH_ semantics there).
• Remaining gap, disclosed for completeness: the template-shift path in ExcelWriteFillExecutor (prepareData re-stored around line 512) re-emits template static text unescaped as well; folding it in would grow this change's scope and it needs a template-authoring-intent discussion, so it is left as is.
• Orthogonal to open PRs: fix(sheet): escape hex sequences in in-memory XLSX writes too #1223 (this author) narrows the handler's cell-kind guard — this change composes with it (in-memory heads/fills need both) and the diffs do not overlap; perf(sheet): recycle CellWriteHandlerContext across cells of a write #1209's context-recycling hunks sit on adjacent lines in the same two methods but are semantically unrelated and merge cleanly; refactor: decouple read/write responsibilities and introduce ColumnBinding #1128/feat: honor wildcard custom converters when reading #1086 touch other regions entirely.

[skytin1004]

@Sean-Walker0 Thanks for the fix! I verified it locally, and everything looks good. LGTM.