Problem
-------
HwpxReader::read_file and read_file_bytes called read_to_string /
read_to_end directly on zip::ZipFile readers with no size ceiling.
ZIP allows extreme compression ratios, so a few-KB .hwpx can claim a
single section.xml entry that expands to multi-GB — OOMing the host.
Any downstream (CLI, WASM, browser extension, VS Code) inherits the
risk since all of them funnel through parse_hwpx → HwpxReader.

Fix
---
Introduce a small read_limited(reader, max) helper using Read::take
so we never allocate past max+1 bytes. Apply:

  - MAX_XML_SIZE     = 32 MB  for text entries (section/header/hpf)
  - MAX_BINDATA_SIZE = 64 MB  for binary entries (images, fonts)

Real-world Korean government HWPX (보도자료·법령·판례) stays well under
these, so legitimate files are unaffected. Over-limit entries surface
as HwpxError::ZipError with "decompression bomb" in the message —
callers see a clean parse error instead of a crash.

Rationale for thresholds
------------------------
MDM (https://github.com/seunghan91/markdown-media) has been running
the same 32/64 MB caps in production across ~500 real HWPX fixtures
with zero false positives; see MDM commit a94b459 for the original
application of this pattern across HWP/HWPX/PDF parser paths.

Tests
-----
Five unit tests in parser::hwpx::reader:
  - under / at / over cap boundary for read_limited
  - a synthetic zip-bomb entry (MAX_XML_SIZE + 1 bytes of 'A',
    compressed to <1 MB) is rejected with ZipError

Full suite: 789 passed, 0 failed (baseline + 5 new).

No public API change: HwpxError variants unchanged, method signatures
unchanged. MAX_XML_SIZE / MAX_BINDATA_SIZE are exposed as pub const
so integrators can read the current caps.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>