fix: reject non-minimally encoded varints

[spokodev]

The unsigned-varint spec requires that varints be minimally encoded, but varint.decode accepts overlong encodings such as [0x81, 0x00] (a non-minimal encoding of 1).

CID.decode, CID.decodeFirst, CID.inspectBytes and Digest.decode all read their varint prefixes (version, codec, multihash code, digest length) through this function. As a result, distinct byte sequences decode to .equals()-equal CIDs and re-encode to different bytes than were supplied — content addresses become malleable, which can defeat dedup/cache-key logic that assumes a canonical binary form.

A varint is non-minimal exactly when its final (most-significant) byte is a redundant zero group, so the check is length > 1 && lastByte === 0.

import { varint } from 'multiformats'
varint.decode(Uint8Array.from([0x81, 0x00])) // returns [1, 2]; should throw

Tests added for the varint primitive and for CID.decode rejecting a non-minimal version prefix.

[rvagg]

Nice work, a couple of thoughts on this as is:

• let's add a simple overlong 127 for a boundary case for this, [0xff, 0x00] should reject
• also let's just protect against regressions by checking that interior zero groups still go through, so [0x80, 0x80, 0x01] might be a good case, that'd come out as [16384, 3]

The spec we work adopt here is https://github.com/multiformats/unsigned-varint/blob/master/README.md, and you'll note that even with this we don't fully comply. We should be rejecting varints longer than 9 bytes, so a number like 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x01 should reject.

Also on the encode side we have some problems:

• We allow signed numbers
• We allow non-integers!
• encodeTo() has divergent behaviour because we allow negatives (encodingLength(-1) returns 1, while encode(-1) writes 5 bytes)

I'd be fine merging this with just a bit more test extension so we lock in the behaviour, you're welcome to go further as well in this PR or in a follow-up. As long as we're doing it properly, we could just consider moving varint.js out of vendor and building the validation into the decode process because it'll be more efficient that way.

[spokodev]

Added all three: the overlong [0xff, 0x00] rejection, the [0x80, 0x80, 0x01] → [16384, 3] interior-zero regression, and a length > 9 guard for the 10-byte case (the vendored decoder happily consumes [0x80×9, 0x01] as 2^63 with bytes === 10, so it needed an explicit check rather than relying on the decoder to bail).

I left the encode-side issues (signed / non-integer / the encodeTo divergence on negatives) out of this PR to keep it scoped to decode. Happy to take those in a follow-up, and to build the validation into decode + move varint.js out of vendor as you suggested if you'd prefer that direction.