Implement TC39 Compartments with sandbox-safe capability boundaries

[frostney]

Summary

Implement the Stage 1 TC39 proposal: https://github.com/tc39/proposal-compartments

Implement the current proposal while preserving no ambient authority and no dynamic code generation by default.

Why

This proposal fits GocciaScript's modern ECMAScript surface and the 0.13.0 proposal roadmap. It should extend the engine's existing architecture rather than arrive as a userland shim.

Current behavior

Realm, module loader, virtual module, and opt-in ShadowRealm foundations exist, but no Compartment/endowment/module-map isolation API does.

Expected behavior

Implement the current proposal while preserving no ambient authority and no dynamic code generation by default.

Scope notes

First record realm/global/module/cache/error ownership in an ADR, then implement on Realm and Modules.Loader. Endowments expose only host grants. Dynamic evaluate/source remains behind an explicit unsafe capability flag for security, not compatibility. Do not claim SES hardening. Cover leakage, modules, errors, GC, deterministic mode, and cross-realm calls.

Related bytecode roadmap: #871 and #875. Update relevant documentation and the Goccia proposal inventory. Use the current proposal specification at implementation time; add focused project tests and matching pinned Test262/proposal coverage without regressions.

Acceptance criteria

• Parser/API surface, descriptors, evaluation order, errors, and protocol behavior match the current proposal.
• Implementation uses the identified shared engine seam without a duplicate compatibility shim.
• Focused positive, negative, abrupt-completion, and edge-case tests cover the proposal.
• Relevant project suites, pinned Test262 cases, formatting, and documentation checks pass.