fix: reject a decoded array length that exceeds the stream

[spokodev]

An Array in count mode reads its length from a preceding field and then loops that many times, pushing a decoded element each iteration, with no check that the count fits the stream:

} else {
  for (let i = 0, end = length; i < end; i++) {
    res.push(this.type.decode(stream, ctx));
  }
}

length comes from the input, so a crafted buffer that declares a huge count followed by little payload forces both the loop and the result array to grow far past the input — exhausting memory from a handful of bytes. restructure is the decode engine under fontkit, so a schema with a count-prefixed array of a NUL-terminated string (the default new String(), whose element is zero-width at EOF and so never fast-fails) is a reachable, idiomatic surface.

Repro

const array = new r.Array(new r.String(), r.uint32);
array.fromBuffer(new Uint8Array([0x00, 0x01, 0x86, 0xa0, 0x00])); // count=100000, one byte of payload

Heap grows linearly with the declared count; at uint32 max it is unbounded. (Numeric-element arrays happen to self-limit because a DataView read throws past EOF, so the reachable shape is a subarray/pointer/string element.)

Fix

Every element consumes at least one byte, so a count larger than the bytes remaining in the stream is unsatisfiable — reject it before looping. The eof and lengthInBytes modes are untouched, and the guard never fires on valid data.

Test

Adds a case: a uint32 count of 100000 with one payload byte must throw. It fails on master ("Missing expected exception" — the decoder runs the full loop) and passes with the fix. Full suite: 243 passing.