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