runtime/binary-data: complete ArrayBuffer/DataView view and prototype semantics (c262)

[andrewtdiz]

User outcome

Binary-heavy packages, Fetch bodies, crypto, encoders, and protocol code should be able to rely on ArrayBuffer/DataView shape, brand checks, and byte access semantics.

Current signal

Tested on current origin/main bf9802213 with Test262 pinned to 4249661388e5d3f92a85186213da140a6481490f and Node v25.9.0.

Command:

scripts/test262_subset.py --root vendor/test262 --dir built-ins/ArrayBuffer built-ins/DataView --max 80 --timeout 8 --sample-cap 20 --report target/test262-reports/arraybuffer-dataview.json

Result: pass=40, runtime-fail=40, parity=50.0%.
Per dir: built-ins/ArrayBuffer pass=27/runtime-fail=30; built-ins/DataView pass=13/runtime-fail=10.

Representative failures:

• built-ins/ArrayBuffer/allocation-limit.js: huge lengths should throw RangeError.
• built-ins/ArrayBuffer/isView/arg-is-dataview-subclass-instance.js: ArrayBuffer.isView should recognize DataView subclass instances.
• built-ins/ArrayBuffer/isView/invoked-as-a-fn.js: static method is missing/not callable through the expected surface.
• built-ins/ArrayBuffer/prototype/byteLength/*: getter/descriptor/brand checks are incomplete.
• built-ins/ArrayBuffer/prototype/slice/end-default-if-undefined.js: slice default end behavior is wrong.

Shortest useful fix

Cover the binary object model used by app code before broader SharedArrayBuffer work:

• Reify ArrayBuffer constructor/prototype static surface, including isView, name, length, and descriptors.
• Implement/align ArrayBuffer.prototype.byteLength getter brand checks and descriptors.
• Fix ArrayBuffer.prototype.slice bounds/default behavior for ordinary buffers.
• Ensure DataView instances and subclasses are recognized by view checks.
• Add focused c262 regression fixtures for the samples above.

Acceptance

• Representative Test262 cases above pass.
• The targeted ArrayBuffer/DataView slice improves materially from the current 50.0% baseline.
• Existing Buffer, Fetch body, and TypedArray smoke tests continue to pass.

JIT product notes

Core: ordinary ArrayBuffer/DataView semantics used by real packages.
Defer: SharedArrayBuffer, Atomics, resizable/growable buffers, and transfer semantics unless already required by these samples.
Future signal: widen when Fetch/crypto/Buffer package fixtures expose deeper binary edge cases.

[proggeramlug]

Shipped a focused ArrayBuffer sub-fix toward this epic in #4045 (v0.5.1091): new ArrayBuffer(n).resizable now returns false and .maxByteLength returns n (were both undefined).

Perry has no resizable ArrayBuffers, so a plain ArrayBuffer is always non-resizable and maxByteLength === byteLength. Added both getters to the registered-buffer property path, scoped to a plain ArrayBuffer — DataView/SharedArrayBuffer/typed-array views correctly still return undefined (matching Node, verified).

Still open under this epic: the DataView/ArrayBuffer distinct-identity gap — new DataView(ab) and ab share one backing address in Perry, so Object.prototype.toString.call(dv) reports [object ArrayBuffer] instead of [object DataView]. That needs DataView to carry its own identity separate from the backing buffer (a deeper reification).

[proggeramlug]

Shipped a typed-array brand fix toward this epic in #4061 (v0.5.1097): Object.prototype.toString.call(new Int32Array()) now returns [object Int32Array] (was [object Number]), covering all 12 typed-array kinds — plus Symbol/BigInt brands.

Root cause was a split dispatch: the callable Object.prototype.toString (object_prototype_to_string_thunk) had its own coarse brand logic separate from js_object_to_string, mis-tagging raw-i64 typed arrays as [object Number] (a small pointer bit pattern reads as a finite f64). Fixed by delegating the thunk to js_object_to_string so both paths share the full brand table, then adding the typed-array/Symbol/BigInt arms there.