v5: *: Reject malformed variable-length integers

[hiddeco]

Variable-length integer decoders accepted continuation chains long enough to push the running shift past the bit-width of their accumulator, producing out-of-range values that propagated into buffer allocation hints and on-disk size fields.

Mirror the bound from canonical Git's unpack_object_header_buffer1: reject any continuation byte that would shift past the type's capacity. The same rule applies to Scanner.readLength, the package-local decodeLEB128/decodeLEB128ByteReader, and ReadVariableWidthInt; decodeLEB128 now returns an error so callers surface invalid input rather than silently zeroing the result.

Add defense-in-depth at every call site that allocates from a parsed length: cap bytes.Buffer.Grow hints in the parser at 1 GiB, clamp the slice and maps initialized from Parser.count at a 4 Mi-entry hint so a hostile object count cannot request a multi-gigabyte allocation, and validate OFS-delta back-references in the scanner (must be > 0 and <= h.Offset).

Cover the new behavior with unit, parser-level regression and fuzz tests (FuzzReadLength, FuzzDecodeLEB128,
FuzzDecodeLEB128ByteReader, FuzzParser).

Backport of #2090.

[pjbgf]

@hiddeco thanks for working on this. 🙇