fix(runtime): eval-realm `structuredClone` and `BroadcastChannel` mishandle shared memory

Problem

The JS fallback structuredClone special-cases only ArrayBuffer, so a SharedArrayBuffer falls through and becomes {}; typed arrays over one break and there's no transfer option. The fallback BroadcastChannel only works within a single context. node/util.zig panics in isSharedArrayBuffer.

Evidence (origin/main @ d4b219507)

• packages/runtime/src/jsc/misc_globals.zig:174-213
• packages/runtime/src/jsc/misc_globals.zig:214-240
• packages/runtime/src/node/util.zig:605-607

Scope

• Clone preserves SAB identity (same backing memory) or throws DataCloneError; support transfer.
• BroadcastChannel fails loudly where cross-context delivery is unsupported.
• Implement util.types.isSharedArrayBuffer without panicking.

Acceptance criteria

• In the HOME_NATIVE_RUN realm, structuredClone(sab) shares memory (or throws DataCloneError); tests cover typed arrays over SAB.

Links

Part of #814.

Direct-to-main progress: b611cf7 adds guarded SharedArrayBuffer cloning, ArrayBuffer transfer with rollback, fail-loud BroadcastChannel behavior, and non-panicking util.types.isSharedArrayBuffer across exactly three files. Verification passed: home_rt_no_jsc build test (3/3 steps), node/util.zig (16/16 tests), Pickier, zig fmt/check, diff check, and exact-source JS oracles for shared backing identity, typed-view aliasing, transfer/detach, rollback, unsupported-SAB DataCloneError, BroadcastChannel NotSupportedError, and spoof-resistant util detection. The focused native home_rt test was attempted under 3600 MB and the hard 3840 MB cap; the guard stopped the full JSC link at 3743 MB and 4134 MB respectively, so HOME_NATIVE_RUN execution is not claimed and this issue remains open pending a safely linkable native test or CI confirmation.