`saxen` doesn't decode character references (`é`, `&`, etc) itself:
it passes a `decodeEntities()` function to its `text` / `openTag` handlers
for the consumer to call, and `parseXmlStream.saxen.js` never called it.

On top of that, the copy-pasted `saxen` wrapper in `saxen/parser.js` had
`return Parser(options)` at the top of the function body, so the top-level
`var` initializers below it (`ENTITY_PATTERN`, `ENTITY_MAPPING`, etc) never
ran — hoisting made the functions available but left the variables
`undefined`, turning `decodeEntities()` into a silent no-op
(`s.replace(undefined, ...)` matches nothing). The `return` was moved to
the bottom, mirroring `parseXmlStream.saxen.code.js` which already had it
in the right place.

This is a regression introduced in `9.3.0` by the migration from the DOM
parser (which decoded character references natively) to the SAX parser.
It affects any file whose XML escapes characters as references — e.g.
`openpyxl` escapes all non-ASCII text (`é` → `é`) — as well as
sheet names and other attribute values containing `&`, `<`, `"`, etc.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FBbGKM9Kt8imm9H7nysqjb

Fix XML character references not being decoded in cell values and attributes (regression in 9.3.0)

See merge request !10

Passing a non-ZIP file — most commonly a legacy binary `.xls` (an OLE2
Compound File, not a ZIP) — surfaced an obscure error leaked from the
transitive unzip dependency (e.g. `invalid signature: 0xe011cfd0`, the
first four bytes read little-endian), with no stable way to detect it.
Consumers were left string-matching an internal message (Hyrum's law).

Validate the input's leading bytes at the two zip-layer entry points and
throw an Error carrying a documented, stable `code` (the convention
Node.js uses for its own errors):
- `LEGACY_XLS` — OLE2/CFB signature (binary `.xls`)
- `NOT_A_ZIP`  — any other non-ZIP input

Input starting with the ZIP signature ("PK") passes through unchanged.
The Node.js stream path inspects the leading bytes without consuming them
(they are `unshift`ed back), accumulating across chunks. The cost is a
<=4-byte comparison, with no measurable performance impact.

Per maintainer feedback on MR !11: instead of plain `Error`s with a `code`
property, throw an `InvalidInputError` carrying a stable `reason` property
(`XLS_NOT_SUPPORTED` or `NOT_A_ZIP_ARCHIVE`), following the convention of
the existing schema-parsing `InvalidError` class. The class is exported
from all four entry points, declared in the TypeScript types, and
documented in a new README "Errors" section.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X6EAYvxEM7FfDYSZAKJCpq

Per maintainer feedback on MR !11:
* `XLS_NOT_SUPPORTED` -> `XLS_FILE_NOT_SUPPORTED`
* `NOT_A_ZIP_ARCHIVE` -> `FILE_NOT_SUPPORTED`
* The README "Errors" section is commented out, to be uncommented
  at the next release.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X6EAYvxEM7FfDYSZAKJCpq

Reject non-ZIP input (e.g. a legacy binary `.xls`) with a stable error `code`

See merge request !11