ESM module-init code is lowered with is_strict_fn: false — top-level strictness is wrong for some lowerings

[proggeramlug]

Module-init code is lowered with is_strict_fn: false even for an ESM, which is always strict (crates/perry-codegen/src/codegen/entry.rs:825 and :1537; deliberate per entry_outline.rs:677).

It happens not to bite #9394 because a[i] = v lowers to Expr::PutValueSet, which carries the real ctx.current_strict. But any Expr::IndexSet produced by a different lowering — for heads, destructuring — reads the wrong strictness at module top level, so a rejected write there will silently no-op in code that is specified to throw.

No end-to-end reproducer yet; this is a latent correctness hazard found by reading the strictness plumbing while fixing #9394, and it is filed so the next person touching module-init lowering knows the flag is not trustworthy there.

Worth pairing with #(the strict ordinary-object write issue filed alongside this one), since both are about strictness not reaching a store site.

[proggeramlug]

Fixed by PR #9458: Module::init_is_strict is set beside module_strict, read at both entry sites and threaded into outlined chunks — and joins the module stable hash so a cached sloppy compile can't be reused for a strict module. test_gap_9423_module_init_strictness.ts. Verified on main 0a1c137d90 with a fresh build: fixture byte-identical to node --experimental-strip-types (stdout, stderr, and exit code).
Module top-level this is deliberately out of scope (Expr::ModuleTopThis is a module-goal decision that never consults strictness; it still diverges from node).