fix(catalog): encode module aliases before constructing script code

[miguel-heygen]

What

Route the shared module alias map through the same HTML-safe JSON encoder used for inline script strings. The bundle wrapper previously interpolated plain JSON directly into generated JavaScript, which left two CodeQL improper-code-sanitization findings after #5090.

The existing helper now accepts a string or a string map. It still encodes < and Unicode line separators before construction. Current aliases are fixed trusted strings, so this does not claim an attacker-controlled exploit, and generated payloads remain byte-identical.

Validation

• Red control: the completed JavaScript CodeQL scan of fix(catalog): 3D previews load their scripts under the docs host's script policy #5090 reports two findings originating at alias-map serialization. The follow-up scan must clear them; neither is dismissed.
• Inlining tests: 15 passed, 0 failed, 0 skipped on each of three serial Linux runs. Scripts typecheck, lint, and formatting exit 0.
• Regenerating all five affected block payloads and both vendor JSON files preserves every SHA-256 hash.
• An initial isolated-checkout typecheck could not resolve unbuilt workspace dependencies. Validation was repeated successfully in the prepared Linux environment; the tested source SHA-256 equals the committed file.

No player or Studio source changes.

[terencecho]

Approving d03765af.

Encoding is correct and complete for what it targets. jsLiteral is the old jsStringLiteral widened to accept the alias map. It runs JSON.stringify and then escapes <, U+2028 and U+2029, so it is applied exactly once at each of the three sites (classicBundle alias map, codeStep, glass bootstrap). I ran old vs new in node:

• The real alias map {"./three.module.min.js":"three"} serializes byte-identically.
• A hostile map (</script><script>…, </SCRIPT>, U+2028/2029, quotes, backslash, <!--) comes out with no raw < or line separators and round-trips through eval.
• The double layer (classicBundle code string, then codeStep's jsLiteral) decodes once to the right key lookup, so there is no double-encoding.

Output unchanged: only scripts/catalog-script-inlining.ts changes (6 lines), and the Catalog payloads check passes at this head, so the committed payloads still match the generator.

CodeQL on the exact head: the PR merge commit 5f2f7cf2 has parents main f835f831 and head d03765af. Its JavaScript, Actions and Python analyses report 0 results, and the CodeQL check and the Analyze (javascript-typescript) check are both success. The two alerts this targets (#1134 scripts/catalog-script-inlining.ts:138, #1135 :139) are still open on main until this merges and main is rescanned; neither is dismissed.

CI at this head: all required checks pass (43 pass, 17 skipping, 0 pending, 0 failing); no review other than mine at this head.

Non-blocking:

• Alert #1136 (js/bad-tag-filter, the /<script>/ regex near :377) is open on main and outside this PR. The PR-ref scan reports 0 for it, and I did not find out why. Check main after merge.
• Three interpolations still use plain JSON.stringify into generated code (:110 module specifier, :159 vendor URL and ${key}.js, :164 step name). They are fixed trusted strings and CodeQL does not flag them. They could take jsLiteral for consistency.

— Review by tai (pr-review)