fix(sheet): escape hex sequences in in-memory XLSX writes too

[Sean-Walker0]

Purpose of the pull request

EscapeHexCellWriteHandler is registered by default for XLSX writes to keep literal _xHHHH_ sequences intact across a round trip. Its guard required cell instanceof SXSSFCell, so in-memory writes (inMemory(true), whose cells are XSSFCell) were skipped entirely and a literal sequence was stored unescaped: POI's reader decodes _xHHHH_ to the character it names, so "_xB9f0_ and _x1234_" round-tripped as "맰 and ሴ" — silent data corruption on exactly the mode users pick when they need POI features that streaming does not support.

No issue exists for this yet; found while reviewing the default handler set.

What's changed?

The guard now accepts both OOXML cell kinds, SXSSFCell (streaming) and XSSFCell (in-memory). XLS (HSSFCell) and CSV (CsvCell) keep being skipped on purpose: they have no _xHHHH_ decoding, so escaping there would corrupt literals — which is exactly what the existing across-formats round-trip test pins, and those tests pass untouched.

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

EscapeHexInMemoryWriteTest (default handler registration, no explicit handler):

• inMemoryWriteRoundTripsLiteralEscapeSequences — red before (expected: <_xB9f0_ and _x1234_> but was: <맰 and ሴ>), green after;

• streamingWriteRoundTripsLiteralEscapeSequences — pins the default-handler streaming path, green before and after.

• Existing escape tests (EscapeHexCellWriteHandlerTest 19 cases incl. the HSSFCell skip pin, EscapeHexCellWriteHandlerRoundTripTest across XLSX/XLS/CSV): all pass unmodified.

• ./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: in-memory XLSX writes now escape _xHHHH_ literals like streaming writes do. Writers whose literal files intentionally contain decodable _xHHHH_ (relying on the previous in-memory leak) would see them preserved instead of decoded — that preservation is the handler's documented purpose.
• Remaining coverage gap (not touched here, disclosed for completeness): header cells and multi-variable fill cells are written via setCellValue outside the afterCellDataConverted hook, so they are never escaped in any mode. Fixing that spans the head and fill write paths and seemed worth its own discussion rather than folding into this fix.
• Orthogonal to open PRs: no open PR touches EscapeHexCellWriteHandler; the two open PRs touching DefaultWriteHandlerLoader (refactor: Improve the basic javadoc content #1181 javadoc, feat: add support for ODS file format with read/write capabilities #745 ODS case) do not overlap this file.