fixed integer overflow in envelope.go

[tahadostifam]

Fix makeEnvelopePrefix type safety for 32-bit builds

The original implementation of makeEnvelopePrefix accepted size int and compared it against math.MaxUint32.

This caused a build failure on 32-bit architectures (e.g. GOARCH=arm GOARM=7) because int is 32-bit on those platforms, and the constant math.MaxUint32 (4294967295) cannot fit in an int without overflowing.

What changed

Updated the function signature to accept size uint32 instead of int.

Removed the redundant bounds check (size < 0 and > math.MaxUint32), since uint32 already encodes the valid domain for the 4-byte envelope length field.

Ensured that the type matches the protocol specification: the envelope length prefix is always a 4-byte unsigned integer in big-endian order.

On both 32-bit and 64-bit builds, the function now works without type conversion or overflow issues.

Callers passing len(payload) must explicitly cast to uint32 and can guard against oversize payloads (len(payload) > math.MaxUint32), which matches the maximum representable size of the envelope field.

This aligns the code with the protocol definition and avoids platform-dependent build errors.

Related Issue

#886

[emcfarlane]

Thanks for looking into it, closing as fixed in #887 . Will get a release out.