Security: replace the vulnerable XLSX parser in XlsxConverter

The `XlsxConverter` in `src/converters/xlsx.ts` reads user-provided `.xlsx` files through the direct `xlsx@^0.18.5` dependency. That npm release is affected by two public high-severity advisories:

- [GHSA-4r6h-8v6p-xvw6](https://github.com/advisories/GHSA-4r6h-8v6p-xvw6): prototype pollution
- [GHSA-5pgg-2g8v-p4x9](https://github.com/advisories/GHSA-5pgg-2g8v-p4x9): ReDoS

This converter is an especially relevant boundary because workbook contents are the input being transformed to Markdown. The existing tests already include real XLSX fixtures, including an empty-sheet case, so they should provide a useful migration guard.

Two current options are:

1. Use SheetJS CE 0.20.3 from the [official tarball](https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz).
2. Preserve all imports with `"xlsx": "npm:@stackline/xlsx@^1.0.6"`.

The npm alias keeps `import * as XLSX from "xlsx"` unchanged. `@stackline/xlsx` is a hardened compatible fork with regression tests for both advisories and requires Node 20+, matching the repository CI.

Disclosure: I maintain the Stackline fork; the official tarball is listed as a neutral alternative. A useful acceptance check would be the existing Vitest suite plus a malformed large workbook/CSV fixture and a malicious-header prototype-pollution assertion.

Start in src/converters/xlsx.ts and inspect the existing Vitest tests and XLSX fixtures, including the empty-sheet case. Compare the two listed parser options for compatibility with the current imports and Node 20 CI. Done means the existing suite passes and coverage includes a malformed large workbook/CSV case plus a malicious-header prototype-pollution assertion.

Written by the indexing model from the issue text.