A 512-byte workbook can provoke a multi-gigabyte allocation and abort the process

Affected versions passed caller-supplied bytes to `calamine`'s `Xlsx::new` without first checking that they were a ZIP archive. `Xlsx::new` tests for password protection on its first line, which parses the input as an OLE/CFB container, and a sector-count field read from the file's own header reaches `Vec::with_capacity` without being checked against the file's actual length. A 512-byte input can therefore request several gigabytes; 9,261,285,372 bytes was measured. **The oversized allocation is always attempted. Whether it aborts depends on what the allocator can satisfy.** On a large host with overcommit the reservation is granted untouched and the call returns an ordinary "not an xlsx file" error, which looks like a malformed file being correctly rejected. Under a memory limit the same bytes give `memory allocation of N bytes failed` and the process aborts, which is not a `Result` a caller can handle. Containers with a memory limit, small hosts and CI runners are where this lands, so testing on a development machine can wrongly suggest the crate is unaffected. Every entry point reaches it, not only `compare_bytes`: the path- and reader-based APIs funnel through the same internal open. Neither `Limits::default()` nor `Limits::hardened()` prevents it, because `max_input_bytes` bounds the length of the input while the allocation's size comes from a field inside it. Fixed in 3.2.0, which declines input that does not begin with the ZIP magic before the parser sees it, removing