Evaluate JIT options (copy-and-patch vs MIR) and recommend go/no-go

Summary

Spike: evaluate whether a JIT is worth pursuing, which technique, and at what cost — then recommend go / no-go. Investigation and a one-hot-loop prototype, not production engine code.

Why

Throughput parity with reference embeddable engines is reachable without a JIT — those engines are bytecode interpreters — so the near-term levers are value unboxing (#860) and deeper inline caches (#861). A JIT only matters beyond that, and it is in tension with the sandbox-first posture: a JIT writes executable memory at runtime, which is exactly the dynamic code generation the engine disables by default (eval and the Function constructor are off unless explicitly opted in).

Current behavior

No JIT; a register bytecode VM with shape-validated, monomorphic inline caches.

Expected behavior

A written recommendation covering:

• Whether the non-JIT path (#860/#861) reaches the throughput target first (expected: yes).
• If pursued: copy-and-patch (low effort, as shipped in CPython 3.13) vs MIR (a small C JIT library) as the front-runners, with a one-hot-loop prototype measuring the realistic ceiling.
• The W^X / attack-surface cost, and whether a JIT must be opt-in-only (like --unsafe-ffi) or a separate non-sandbox build.
• A clear verdict: non-goal / opt-in-only / pursue.

Scope notes

• Deliverable is a design doc + recommendation. Parent #822.

Start with the current register bytecode VM and the throughput work in #860 and #861. Compare copy-and-patch with MIR using a one-hot-loop prototype, and document the throughput ceiling, W^X and attack-surface implications, and sandbox or opt-in constraints. Done means a design document with a clear non-goal, opt-in-only, or pursue recommendation under parent #822.