Fix cross-realm TypedArray and ArrayBuffer detection

[ItsChrisHickman]

Problem

isTypedArray and isBufferSource use instanceof ArrayBuffer checks that silently fail when values cross JavaScript realm boundaries. This happens whenever WebGL content runs inside an iframe and receives buffers from the parent page (or vice versa) — each realm has its own ArrayBuffer constructor, so instanceof returns false for objects created in the other realm. This has as real world application for THREE.js applications with javascript SDKs that provide the ability add THREE based enhancements.

The result is that bufferData calls reject perfectly valid TypedArray and ArrayBuffer inputs with an "unsupported src type" error, even though the data is correct.

Fix

• isTypedArray: Replace v && v.buffer && v.buffer instanceof ArrayBuffer with ArrayBuffer.isView(v). This is the spec-recommended way to check for TypedArrays and DataViews — it works across realms by design and is supported in all browsers since IE10.

• isBufferSource: Add an Object.prototype.toString.call(v) === '[object ArrayBuffer]' fallback alongside the existing instanceof check. The instanceof fast path still covers same-realm buffers with zero overhead; the fallback only activates for cross-realm cases.

Why this is safe

Both replacement APIs are strictly more correct than instanceof:

• ArrayBuffer.isView returns true for the exact same set of types (all TypedArray variants + DataView) that the original duck-typing check targeted, but without the realm limitation.
• The Object.prototype.toString fallback is the standard pattern for cross-realm type detection used throughout the JS ecosystem (e.g. lodash, Node.js internals).
• No new dependencies, no behavioral change for same-realm usage — existing consumers see identical results.