bug: chunkedReader.Read read up to math.MaxInt on 32bit platforms

[nemith]

The chunkedWriter correctly works with the max int size on 32bit platforms but the read side was still assuming math.MaxUint32. Since len(p) is weirdly signed this doesn't work so cap it at Math.MaxInt the same way we do for the writer.

I really wish Go used usize for things like this cause this is just a pain in the ass.

[Copilot]

Pull request overview

This PR fixes a bug in the chunkedReader implementation where it was using math.MaxUint32 instead of math.MaxInt to cap buffer sizes on 32-bit platforms. Since Go slice lengths are signed integers (type int), this caused issues on 32-bit systems where math.MaxUint32 exceeds the maximum value of int.

Key changes:

• Moved maxChunkSize constant from chunkedWriter.Write method to package-level scope for reuse
• Updated chunkedReader.Read to use maxChunkSize instead of math.MaxUint32, ensuring consistency with the writer and proper handling on 32-bit platforms

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The comment mentions "MaxInt32" but should refer to "MaxInt" for accuracy. On 32-bit systems, math.MaxInt equals math.MaxInt32, but on 64-bit systems, math.MaxInt equals math.MaxInt64. The comment should be updated to reflect that slice lengths are limited to math.MaxInt (not specifically MaxInt32).

Suggested change

	// RFC 6242 allows up to MaxUint32 (4294967295), but on 32-bit systems
	// slice lengths are limited to MaxInt32. We use the minimum of both
	// to ensure compatibility across all architectures.
	// RFC 6242 allows up to MaxUint32 (4294967295), but slice lengths are
	// limited to math.MaxInt. We use the minimum of both to ensure
	// compatibility across all architectures.