CBOR: bound declared array/map length against remaining bytes

## Summary
The definite length array and map decoders allocate and loop on the declared element count without checking it against the bytes that remain. A tiny input with a huge declared count and no element data drives a multi gigabyte fill, because reads past the end of the buffer decode as 0n instead of throwing, so the loop runs to the declared count. The result is a fatal, uncatchable heap OOM. The byte string decoder already guards this with a remaining length check; the array and map branches do not.

## Affected
packages/evolution/src/CBOR.ts decodeArrayAt definite branch (L1942-1951)
packages/evolution/src/CBOR.ts decodeMapAt definite branch (L1996-2025)
reference for the correct guard: decodeBytesAt (L1865)

## Fix
Before allocating or looping, bound the declared length by the remaining bytes (each array element needs at least 1 byte, each map entry at least 2), and throw a CBORError when the declared length exceeds what remains. Mirror the existing byte string check.

## Regression test
- given: Data.fromCBORHex("d8799a7fffffff") (7 bytes, declares ~2.1 billion elements)
- before fix: process aborts with a fatal heap OOM (uncatchable)
- after fix: throws a bounded CBORError that a caller can catch
- control: the byte string case (5a7fffffff) already throws and should stay throwing

Must FAIL on main today and PASS after the fix.

## Reference
Report 8

Read packages/evolution/src/CBOR.ts, starting with decodeBytesAt and then the definite branches of decodeArrayAt and decodeMapAt. Exercise Data.fromCBORHex("d8799a7fffffff") and the byte-string control case; done means oversized declared lengths throw a catchable CBORError without attempting allocation or looping.

Written by the indexing model from the issue text.