fix(npy): avoid unbounded allocation when reading the .npy header (CWE-770)

[li-jin-quan]

I found a small DoS in read_header.

It reads a length from the .npy file, then allocates that much before checking the bytes are actually there:

let mut header_len = vec![0u8; header_len_len];  // 2 bytes (v1.0) or 4 bytes (v2.0)
reader.read_exact(&mut header_len)?;
let mut header = vec![0u8; header_len];          // <-- size comes from the file
reader.read_exact(&mut header)?;

The v2.0 length is 4 bytes, so a 14-byte file can ask for up to 4 GiB.

I measured it with a counting allocator: 1 GiB allocated from 14 bytes. On a small machine this aborts the process.

Fix: read with take(header_len) instead of pre-allocating, then check the length.

file	before	after
14 bytes, 1 GiB header	1,073,741,824 bytes	92 bytes + a clean "truncated" error
well-formed file	unchanged	unchanged

take caps how much is consumed, so the rest of the stream is untouched — well-formed files behave exactly as before.

Added two tests: header roundtrip, and the truncated case.

Does this look right to you? Happy to adjust anything.

One note: Tensor::from_reader has the same shape (vec![0f32; elem_count]). I left it out on purpose to keep this PR small — happy to do it as a follow-up if you want.

[li-jin-quan]

Hi — gentle ping on this one too, about a week old.

The .npy header reader trusts header_size straight from the file. A crafted value makes it allocate before validating anything. This bounds the read by what's actually in the file.

Same question as my other PR — worth taking, or would you rather I close it?