createRealm installs a full $262 on the new realm and returns it

[lahma]

test262's INTERPRETING.md specifies that $262.createRealm() "creates a new ECMAScript Realm, defines this API on the new realm's global object, and returns the $262 property of the new realm's global object".

Jint returned the new realm's global object and installed only global and evalScript on it. So otherRealm.$262 was undefined and otherRealm.$262.detachArrayBuffer could not be reached. It worked at all only because it set global on the global itself, so other.global happened to resolve.

The fix

Test262Object.Install gains a (Engine, Realm) overload that builds $262 from the target realm's intrinsics using the realm-pinned ClrFunction constructor, and createRealm now installs a full $262 — createRealm, detachArrayBuffer, evalScript, gc, IsHTMLDDA, AbstractModuleSource, global — on the new realm's global and returns it.

One thing worth recording, because it is not obvious: realm.Intrinsics.Object.Construct(...) does not give you an object of that realm. A plain construction lands on new JsObject(engine), whose prototype comes from the active realm. The $262 object and the %AbstractModuleSource% prototype therefore use OrdinaryObjectCreate(engine, realm.Intrinsics.Object.PrototypeObject) instead. That same behaviour is the root cause of the "wrong realm's result" exclusions still listed in the file.

Compatibility

All 284 test262 files that call createRealm were surveyed: 297 uses chain .global directly, and of the 9 that bind the result to a variable the only properties ever read are .global (24) and .evalScript (2). Both survive. No file reads .global off a variable already holding the new global, so dropping the old self-reference is safe. Test262AgentManager's minimal worker $262 is untouched.

Tests

Jint.Tests/Runtime/Test262HarnessObjectTests.cs — 4 tests, all failing against unfixed code. They assert the returned object carries every member, that result.global is a distinct global with distinct intrinsics, that the installed functions genuinely belong to the new realm, and that detachArrayBuffer detaches a buffer created in that realm.

Because this touches the harness every cross-realm test262 file depends on, the 219 generated test methods covering all 498 files that mention $262 were run in sequential chunks: 46,905 passed, 0 failed.

Exclusions

Frees staging/sm/TypedArray/set-wrapped.js.

constructor-buffer-sequence.js is not freed and stays excluded, moved to its own block with a precise reason: with the $262 gap closed it progresses to a realm-independent failure. InitializeTypedArrayFromArrayBuffer must raise the misaligned-byteOffset RangeError (step 3) before evaluating ToIndex(length) (step 5); Jint evaluates both ToIndex calls at the call site first, so new Int32Array(buffer, 1, poisonedValue) reports the poisoned value's own error. Those are the same two lines as the int-truncation bug behind constructor-byteoffsets-bounds.js, so one fix removes both entries.

The cross-realm banner is rewritten. Its claim that "an error Jint raises while running a function belonging to another realm is constructed from the current realm's intrinsics" is wrong as a general statement — most built-ins already raise through their own _realm. What remains is a handful of paths that reach for whichever realm is running, in two distinct shapes (wrong realm's error, wrong realm's result), and the comment now says which files are which.

Refs #3021.