DOCX_MAX_HEADER_FOOTER_PARTS may reject legitimate multi-section documents

[llbbl]

Follow-up from #6 (PR #16).

DOCX_MAX_HEADER_FOOTER_PARTS = 64 caps how many word/header*.xml / word/footer*.xml parts the archive inspector will enumerate.

Word writes up to six header/footer parts per section (default / first-page / even-page, for each of header and footer). A document with per-chapter running heads and ~11 or more sections legitimately exceeds 64 — and a multi-chapter handbook is precisely the kind of document this library targets.

The cap was added alongside the aggregate byte budget while fixing a DoS where 400 header parts, each honestly under the per-part cap, summed to 11GB RSS and a fatal (uncatchable) heap abort. The byte budget is the real memory bound; the count cap is belt-and-braces and can be raised substantially or dropped at no memory risk.

Failure mode today is a clear typed DOCX_ARCHIVE_INVALID with no data loss, so this is a usability defect rather than a correctness one.

Tasks

• Raise the cap to something no legitimate document reaches (or drop it and rely on the byte budget plus DOCX_MAX_ARCHIVE_ENTRIES).
• Add a test with a realistic multi-section document (12+ sections, per-chapter running heads) proving it is accepted.
• Re-measure the 400-part hostile archive afterwards to confirm the byte budget still rejects it quickly (currently ~2ms / 92MB).