Correct SES sandbox lockdown initialization

[xdCloudy]

Summary

Fix SES sandbox initialization so Mindcraft actually invokes SES lockdown() instead of recursively calling its own wrapper.

Problem

The current sandbox initialization helper shadows the global SES lockdown function with a local function of the same name. When the helper attempts to initialize SES, it calls itself recursively. The guard flag prevents an infinite loop, but the real SES lockdown configuration is never applied.

This means generated-code execution can continue without the hardening that the surrounding code expects to have enabled.

Changes

• Rename the local initialization wrapper so it no longer shadows SES lockdown
• Explicitly invoke globalThis.lockdown(...)
• Preserve the existing one-time initialization guard
• Keep the existing sandbox configuration and Compartment usage unchanged

Why

The generated-code path relies on SES as a security boundary. Failing to initialize lockdown correctly weakens that boundary and makes the runtime behavior differ from what the code intends.

Compatibility

No profile, command, model, or generated-code API changes are introduced. This only fixes sandbox initialization.

Validation

Validated on the fork CI matrix with Node 20 and Node 22, including dependency installation and JavaScript syntax checks.

[Sweaterdog]

quit spamming our repo with slop