Design a real sandbox boundary for token script execution

[tcsenpai]

CodeRabbit inline: #695 (comment)

Prepared design note: history/token-script-sandbox-boundary.md

Current findings:

• src/libs/scripting/index.ts still executes untrusted token scripts in-process via node:vm.
• Existing hardening (Date.now/Math.random/process/require restrictions plus per-call timeouts) improves determinism but does not create a real security boundary.
• The consensus process still shares the same runtime, event loop, and memory domain with token script execution.
• Earlier remediations Implement L2PS Members E2E Encryption #133 and Add L2PS methods to the SDK once the other points are sufficiently mature #134 reduced state leakage and host-object mutation risk, but they did not solve the underlying sandbox/trust-boundary problem.
• This remains an architectural hardening task, not a local autofix.

Future target:

• Replace the in-process executor model with an isolated execution boundary and explicit message-passing ABI.
• Enforce timeout, memory, and kill semantics at the executor boundary.
• Accept only serialized, schema-validated inputs/outputs.
• Keep consensus-critical failure handling fail-closed.

Acceptance criteria:

• Token scripts no longer execute inside the main node process trust boundary.
• Only serialized, validated data crosses the executor boundary.
• Timeout and memory ceilings are enforced by the executor, not just by cooperative in-process controls.
• Wedged executions can be terminated without depending on script cooperation.
• Hooks and methods cannot mutate host state except through validated returned mutations or storage updates.
• Executor outputs are schema-validated before application.
• Regression coverage exists for timeout, malformed output, executor crash, and representative escape attempts.