[proggeramlug]

Summary

Fixes #3961.

Uint8Array.prototype.buffer and Uint8Array.prototype.slice().buffer now return a real ArrayBuffer instead of the Uint8Array/Buffer itself. The substantive runtime fix landed on main in #4041 (runtime/binary-data: complete ArrayBuffer/DataView view semantics); this PR adds a byte-for-byte parity regression test so the behaviour stays locked.

Verified against Node v25 — identical output:

direct typeof: object
direct instanceof ArrayBuffer: true
direct tag: [object ArrayBuffer]
direct byteLength: 9
slice tag: [object Uint8Array]
slice is Uint8Array: true
slice.buffer typeof: object
slice.buffer instanceof ArrayBuffer: true
slice.buffer tag: [object ArrayBuffer]
slice.buffer byteLength: 9
reread bytes: 1,2,3,4,5,6,7,8,9

The test asserts the ArrayBuffer identity semantically (instanceof, Object.prototype.toString.call, byteLength, byte round-trip) rather than dumping the raw console.log(buffer) representation: Node renders a 9-byte ArrayBuffer (and the Uint8Array(9) line) across multiple lines via its breakLength/number-grouping inspect rules, which is a separate, general console-formatting parity gap unrelated to the return-type bug this issue reports.

Test plan

• test-parity/node-suite/buffer/properties/uint8array-buffer-getter.ts matches Node byte-for-byte.