Import XTB xStation .xlsx account workbooks

[ChristopherDownie]

Fixes #42.

Builds on @zahei's contributed importer (first commit, authored by them): XTB exports one .xlsx per account; closed positions become an entry and an exit fill, open lots become entry fills keyed by XTB position id, and a later workbook that closes the position adds the exit. Cash operations are skipped. The .xlsx reader has no new dependency.

Review fixes (second commit)

Running the patch as submitted showed:

Found	Fix
pnpm typecheck fails in packages/importers (no DOM typings for TextDecoder/DecompressionStream; strict index access on tradeToExecutions)	DOM lib for the package (it already promises browser support); tradeToExecutions typed as an entry/exit pair
The patch's tests fail against its own samples and assert account numbers from real exports; the real workbooks also carry personal metadata	Synthetic workbooks generated in tests in the layout of xStation exports (packages/importers/tests/xtb-fixture.ts); no account data is committed
A held lot followed by a later close with a different size (for example a partial close), or ms-level timing drift, silently left a phantom open position	server/xtb-import.ts checks incoming XTB entries against stored holdings by position id: rounding-level differences (under 1 s, price within 0.1%) are the same lot and are not inserted again; a changed size or side is refused before any writes, with a message naming the position
Holdings lost their asset class: XTB leaves Category blank on lot rows	Lots inherit the category of their ticker's rollup row
Clean workbooks reported 2–3 "skipped rows" (totals, rollups, the reducer note)	Only unknown trade types are counted as skipped
The workbook was reduced in the browser and the server trusted the resulting text; the ZIP reader had no bounds or size limits	The page uploads the .xlsx as base64 (encoding: "xlsx", 5 MB cap) and the server reads it; every ZIP offset is bounds-checked; ZIP64, multi-part, encrypted members and legacy .xls are refused with clear messages; entry count and expanded size are capped and inflation stops past a member's declared size

Verification

• packages/importers/tests/xtb.test.ts (13 tests): closed position with account-currency result, holdings keyed by position id, later close reproducing the holding's entry exactly, fees, mixed accounts, non-XTB workbooks, and reader limits (stored vs deflated, .xls, truncated, declared-size overrun, oversize, encrypted).
• apps/web/tests/xtb-import.test.ts (5 tests): base64 preview/commit and re-import dedupe; holding closed by a later workbook; rounding drift treated as the same lot; partial close refused with nothing saved; AI/mapping/oversized/non-workbook uploads refused.
• apps/web/tests/xtb-import-ui.test.ts (2 tests): the page sends base64 with encoding: "xlsx" for preview and commit, and blocks AI parsing and oversized files before any request.
• Both real workbooks attached to XTB broker .xlsx statement import (closed positions and open holdings) #42 parse correctly locally (not committed).
• Full suite 586/586, typecheck, format, license check, package builds and production build pass locally.
• Checked in the browser with synthetic workbooks: export A stores two open holdings; a later export B closes one as a +45 win, leaves the other open, and adds no duplicate.

Known limits

Partial closes are refused until a real partial-close export shows how XTB reports them. Prices stay in the instrument currency, so a cross-currency position's result is in the account currency but its entry notional is not (documented in docs/importers.md).

Note: this PR and #45 both touch api/import/route.ts and the README format count; whichever merges second needs a small rebase (the count becomes 16).