qjs_v8_compat: add EVAL_IN_FLIGHT tracking to detect re-entrant Module::evaluate
Add enter_eval/leave_eval/eval_in_flight helpers around the
JS_EvalFunction call in Module::evaluate. The skip-already-evaluated
branch now also short-circuits when re-entry is detected: if our own
evaluate is already running for a given handle and a recursive
evaluate call comes back through (e.g. via lazy_load_esm_module from
inside the body), we return a fresh resolved-promise rather than
double-evaluating the same bytecode.
The in-flight track only catches re-entries that flow through
deno_core's lazy_load_esm_module path (and thus our shim). It does
NOT cover the case where QuickJS evaluates a module transitively
inside the same JS_EvalFunction call, because those don't reach our
evaluate.
Combined with the existing mark_all_esm_bytecode_consumed sweep, this
closes the post-eval window. The pre-eval window (mid-body recursive
load before the entry's body has finished) is still unprotected — that
remains the harder cycle to break under QuickJS's eager link model.