bug: XOR-float decoder integer overflow in `leading + trailing + width` and shift-by-64

[minagishl]

Bug Description

The XOR-float vector codec at src/codec.rs:582-589 performs leading + trailing + width as an unchecked u64 add before validating that the sum is <= 64. In release builds (no overflow checks), the sum wraps around u64::MAX and bypasses the guard. Subsequently, payload << trailing can shift by 64 or more, which is undefined behavior in Rust for the shift operator (debug panic, release-mode UB).

Steps to Reproduce

1. Encode a typed-vector with f64 element type and codec=XorFloat.
2. For one element, set leading = u64::MAX - 32, trailing = 33, width = 0. The sum wraps to 1 and passes the <= 64 check.
3. Decode → payload << trailing shifts by 33 (currently safe in this exact example, but the bypassed guard lets the attacker pick trailing >= 64 freely with neighboring values that wrap).

Expected Behavior

Use leading.checked_add(trailing).and_then(|x| x.checked_add(width)), or compare each component against 64 individually, before any shift. Reject the value with InvalidData on any failure.

Actual Behavior

leading + trailing + width is computed without overflow checking; the guard is bypassed; the subsequent shift is undefined.

Environment

• Crate: recurram, XOR-float codec, src/codec.rs:582-589

Additional Context

Severity: High. Same class of bug exists in recurram-zig (decodeXorFloat, tracked as twilic/twilic-zig#5).