Wire up $262.gc for test262 and fix GC access violation in loops

[frostney]

Summary

Add $262.gc() to the bundled $262.js host hooks file, delegating to Goccia.gc() which calls TGarbageCollector.Instance.Collect. This unblocks 28 test262 tests that require host-gc-required. However, a pre-existing GC access violation must be fixed first — the collector crashes when triggered inside traditional for loops with repeated var allocations.

Why

28 test262 tests call $262.gc(). The wiring is trivial (Goccia.gc() is already available in the bare loader), but the GC bug causes access violations under certain allocation patterns, so landing the hook without the fix would turn honest FAILs into SIGSEGV infrastructure failures.

Current behavior

./build.pas loaderbare
cat > /tmp/gc_loop.js <<'JS'
for (var u = 0; u < 3; ++u) {
    var y = [];
    Object.create(y);
    Goccia.gc();
    y.t = 3;
    Goccia.gc();
}
print("done");
JS
./build/GocciaScriptLoaderBare /tmp/gc_loop.js --asi --compat-all
# Error: Access violation

Simple GC calls outside loops work fine:

printf 'var x = {}; x = null; Goccia.gc(); print("ok");\n' | ./build/GocciaScriptLoaderBare --asi --compat-all
# ok

Expected behavior

Both cases should complete without crashing. $262.gc() should trigger a full collection cycle.

Scope notes

Two pieces of work:

1. Wire $262.gc — one-line addition to scripts/test262_harness/$262.js: gc() { Goccia.gc(); }. Trivial once the GC bug is fixed.

2. Fix GC access violation — the crash happens when Collect runs inside a traditional for loop with var redeclarations and Object.create. Likely a mark-sweep issue where objects allocated in the loop body are collected while still reachable from the loop scope. The GC itself is in source/units/Goccia.GarbageCollector.pas:496 (Collect); the crash is in the sweep phase. This is the blocking prerequisite.

Reproduction from test262: staging/sm/regress/regress-596103.js (the simplest test that triggers it).

[frostney]

Additional newly exposed test262 case from the --compat-for-in-loop PR:

• staging/sm/statements/for-in-with-gc-and-unvisited-deletion.js

Reproduction through the pinned test262 runner:

./build.pas loaderbare
bun scripts/run_test262_suite.ts \
  --suite-dir /tmp/test262-suite-pinned \
  --categories staging \
  --filter 'staging/sm/statements/for-in-with-gc-and-unvisited-deletion.js' \
  --mode bytecode \
  --jobs 1 \
  --verbose

Current result is an ordinary conformance FAIL, not wrapper infra:

Error: TypeError: undefined is not a function

In interpreted mode the diagnostic is clearer:

TypeError: $262.gc is not a function
  Suggestion: '$262' is of type 'object' which does not have method 'gc'

A direct no-GC probe for deleting unvisited properties during for...in now passes, so this specific staging failure is blocked on the missing $262.gc host hook / GC stability work tracked here rather than on the new for...in enumeration semantics.