TypedArray: map()/subarray() result SIGSEGVs on JSON.stringify, corrupts under Array.from/spread (slice/filter OK)

[proggeramlug]

Found via a node --experimental-strip-types differential sweep on main (macOS arm64).

The TypedArray returned by .map() and .subarray() is usable for direct element access but is structurally broken for the object/iteration paths: JSON.stringify of it segfaults, and Array.from(...) / spread read garbage. .slice() and .filter() results are fine.

Repro

const m = new Int32Array([1, 2, 3]).map(x => x * 2);
console.log(m[0], m[1], m.length);   // 2 4 3      OK (direct access works)
console.log(JSON.stringify(m));      // SIGSEGV    (node: {"0":2,"1":4,"2":6})

const sub = new Int32Array([1, 2, 3, 4]).subarray(1, 3);
console.log(JSON.stringify(sub));    // SIGSEGV    (node: {"0":2,"1":3})

// Array.from corrupts instead of crashing:
console.log(Array.from(new Int32Array([1,2,3]).map(x=>x*2)));
// node:  [ 2, 4, 6 ]   perry: garbage (wrong element kind/offset)
console.log(Array.from(new Float64Array([1.5,2.5]).map(x=>x*2)));
// node:  [ 3, 5 ]      perry: garbage

What works vs. doesn't

op	result	direct [i] / .length	JSON.stringify	Array.from / spread
.map(cb)	new TA	works	SIGSEGV	garbage
.subarray(a,b)	view	works	SIGSEGV	garbage
.slice(a,b)	new TA	works	works	works
.filter(cb)	new TA	works	works	works

Notes

• map/filter share the same typedarray/species.rs species_create_length -> typed_array_alloc path (which registers the result), and element values store correctly (direct access is right), so the corruption is in how the map/subarray result is registered/headered for the object-enumeration / iterator path, not in the element store. The slice/filter (OK) vs map/subarray (broken) split is the key clue.
• Likely related to the deferred TypedArray cases from fix(runtime): TypedArray + TypedArrayConstructors test262 parity (species/detached/ctor) #4999 and the parity roadmap Parity-to-95% roadmap: remaining clusters mapped (TypedArray branded methods = top lever) #4315; filing standalone because it is a reproducible SIGSEGV with a 2-line repro.

Severity: crash on a common operation (JSON.stringify(typedArray.map(...))).