fix(test): prevent SourceProviderCache teardown trap in corpus adapter

Parent tracking issue: #66

The plain-context Bun corpus adapter reproducibly traps while running the unchanged large Node crypto key-object file:

./zig-out/bin/home-debug test packages/runtime/test/bun-corpus/js/node/crypto/crypto.key-objects.test.ts

Observed twice on macOS/arm64 debug at d3aeb702234a974f76c27b1115cc0531f4fae18e:

• process exits with signal 5 / status 133 and no corpus summary;
• macOS reports EXC_BREAKPOINT (SIGTRAP);
• faulting stack begins in WTFCrashWithInfoImpl → WTF::AtomStringImpl::remove → WTF::StringImpl::~StringImpl → JSC::SourceProviderCache::~SourceProviderCache → JSC::VM::clearSourceProviderCaches during GC finalization.

The real Home full VM is healthy on the identical file:

HOME_NATIVE_VM=1 HOME_CORPUS_FULL_VM=1 \
  ./zig-out/bin/home-debug test \
  packages/runtime/test/bun-corpus/js/node/crypto/crypto.key-objects.test.ts

That strict run completes with 83 pass, 22 upstream skips, 1 TODO, 0 fail, 905 assertions. This isolates the fault to the adapter/runtime lifetime path rather than crypto key-object behavior.

The directory adapter consequently also exits 133 when it reaches this file:

./zig-out/bin/home-debug test packages/runtime/test/bun-corpus/js/node/crypto

Acceptance criteria:

• no signal/trap from the plain-context runner;
• the unchanged key-object file reports a complete summary;
• directory execution reaches and reports every js/node/crypto file;
• no skip/TODO/workload changes and no Bun delegation.

Fixed and pushed in 31c865d1ba8a13f422a7abccc30d0ef6cb9a0e65 (fix(runtime): restore JSC atom-table ownership).

Root cause was the reduced raw-C-API realm entering a Zig host callback while the current WTF thread still named a different JSC VM's AtomStringTable. When an allocating callback happened to request collection, JSC correctly trapped on its mandatory VM/thread table identity assertion. The fix wraps every reduced-realm host callback at the shared registration boundary and re-establishes the callback context's VM atom table before dispatch. The surrounding JSLock continues to restore its entry table when the outermost scope exits.

This is a runtime invariant repair, not a crypto special case. No corpus sources, skips, TODOs, test registration, or Bun delegation changed.

Verification on macOS/arm64 debug:

• before fix: the unchanged key-object adapter file trapped in 2 of 3 fresh processes;
• after fix: 30 of 30 fresh processes completed, each with 83 pass, 0 fail, 23 existing TODO;
• full unchanged js/node/crypto adapter directory: all 17 files executed, 851 pass, 0 fail, 0 unsupported, 23 existing TODO;
• complete native home_rt suite, twice: 1,814 passed, 19 skipped, 0 failed (1,833 total) on each run;
• zig fmt --check packages/runtime/src/jsc/callback.zig and git diff --check passed.

All acceptance criteria for this adapter trap are met, so I am closing this issue. The broader historical GC-stability investigation remains tracked separately in #568.