fix(compile): initialize namespace fields in the multi-module entry point (#1245)

[nickna]

Summary

Fixes #1245. In compiled mode, any program containing both a namespace declaration and a top-level import (which makes the file an ES module) crashed at startup with a NullReferenceException in $TSNamespace.Set, called from the module's $Initialize. The interpreter ran the same program correctly.

Root cause

Namespace objects live in flat static fields ($ns_*) on $Program, shared across every module. A module's $Initialize body only populates them — EmitNamespace emits $ns_X.Set(...) — it never creates them.

• The single-file entry point (EmitSingleFileEntryPoint / EmitExeEntryPointWithUserMain) calls InitializeNamespaceFields(il) at the top of Main, before any top-level code runs.
• The multi-module entry point (EmitModulesEntryPoint, used whenever the program has imports) omitted that call.

So when a module's $Initialize ran $ns_NS.Set("x", 1), $ns_NS was still null → NRE. A namespace in a plain script (no import) was fine because that path uses the single-file entry point.

Fix

Call InitializeNamespaceFields(il) in EmitModulesEntryPoint before the module $Initialize dispatch loop, mirroring the single-file path. Namespace fields are global/flat and defined once, so initializing them all in Main before any module init covers ES-module, script, and lazily-required CommonJS modules alike.

Tests

New NamespaceInModuleTests (runs both interpreter and compiled via ExecutionModes.All):

• namespace + import in the entry file — exported const, import after (the exact issue repro)
• exported function member, import before the namespace
• nested namespaces
• namespace alongside a sibling-module import, with class and enum members

Confirmed the 4 compiled-mode tests fail with NullReferenceException without the fix and pass with it (interpreted always passed).

Verification

• xUnit: 15412 / 0 (baseline 15404 + 8 new)
• Test262: 22 / 0 / 4 skip (matches baseline, interp + compiled)
• TypeScript conformance: 31 / 0 (matches baseline)
• --verify on the fs-free namespace-in-module case is clean; the $M_fs_* / $M_path_* IL-verify errors that appear when importing those facades are pre-existing and orthogonal (tracked as Compiled fs facade emits IL-unverifiable methods (68 --verify errors: $Promise vs Task<object>, object vs string) although it runs #1246).