Out-of-bounds Uint8Array read pushed into an array stores 0 instead of undefined #9039

An out-of-bounds Uint8Array read that flows into an array push stores 0 instead of undefined.

Reproducer

const u = new Uint8Array([7, 8, 9]);
const a: number[] = [];
for (let i = 0; i < 3; i++) { const x = u[99]; a.push(x); }
console.log(JSON.stringify(a), u[99], typeof u[99]);

node:  [null,null,null] undefined undefined
perry: [0,0,0]          undefined undefined

The read itself is right — u[99] prints undefined and typeof says undefined. Only the value that reaches the array is wrong, so the coercion happens on the store/push lane rather than in the typed-array read.

Scope

• out-of-bounds numeric index → wrong (0 for undefined)
• non-numeric key (u["oops"]) → correct, [null,null,null]
• in-bounds reads → correct

That split is the interesting part: the #7700 non-numeric-key path is handled, and this is the neighbouring case that isn't.

Pre-existing, not #9033

Found while auditing #9033 (which extends expr_produces_canonical_raw_f64 to integer-provenance locals — the same push lane), so I A/B'd before attributing. Both --profile perry-dev builds of -p perry -p perry-runtime-static -p perry-stdlib-static, compiled with PERRY_NO_AUTO_OPTIMIZE=1:

The two are byte-identical across my whole 7-case probe, so #9033 neither causes nor worsens this. Recording it explicitly because it sits squarely in the lane that PR touches and would be easy to pin on it.

Why it is worth fixing

An OOB typed-array read is a normal way to reach the end of a buffer, and 0 is a plausible byte value — so unlike a crash this silently produces data that looks legitimate:

for (let i = 0; i < n; i++) out.push(buf[i]);   // n past the end → silent zero padding

Node oracle is the pinned v26.5.1.