Substance follows the same pattern I approved in #33760. The 12k-line diff is dominated by ext/crypto/00_crypto.js (~11.5k lines) where every line is replaced as the file goes from ESM module to IIFE script — almost-zero net (5684+/5634-). The actual semantic surface is small:

Substance walk

• ext/crypto/lib.rs: esm = ["00_crypto.js"] → lazy_loaded_js = ["00_crypto.js"]. Right shape, mirrors #33760.
• ext/cache/01_cache.js: ext/fetch dependencies (Request, toInnerRequest, toInnerResponse, getHeader) bridged via internals since ext/fetch is still ESM. Correct workaround pattern — scripts can't import from other extensions, so cross-extension symbols flow through the internals namespace.
• ext/crypto/00_crypto.js: same wrap. kKeyObject symbol bridge added at ext/node/polyfills/internal/crypto/constants.ts (publishes internals.kKeyObject = kKeyObject) so the now-script-form crypto can read it via internals.kKeyObject.
• Consumer migration: ext/node/polyfills/crypto.ts:170 and internal/crypto/keys.ts:38 both switch import { ... } from "ext:deno_crypto/00_crypto.js" → const { ... } = core.loadExtScript("ext:deno_crypto/00_crypto.js"). runtime/js/90_deno_ns.js does the same for ext:deno_canvas/02_surface.js. These are the exact paths that broke OffscreenCanvas in #33760 before the core.loadExtScript migration — encouraging that they're handled in this PR's initial diff.
• ext/cron skipped: the body acknowledges 01_cron.ts is TypeScript and lazy_loaded_js doesn't transpile. Right scope decision.

Smaller observations

• internals.kKeyObject couples crypto.js to node/constants.ts: this is a load-order-sensitive coupling. If node/internal/crypto/constants.ts doesn't run before 00_crypto.js's IIFE evaluates, internals.kKeyObject will be undefined. Worth confirming the bootstrap ordering — and worth a brief comment in constants.ts explaining why internals.kKeyObject = kKeyObject is there ("publishes for ext/crypto's lazy-loaded script") so a future reader doesn't think it's an internals leak to clean up.
• The // @ts-check and triple-slash references at the top of 00_crypto.js are dropped in the conversion. The IIFE form can't use // @ts-check — that's expected — but it does mean the crypto JS no longer benefits from the TypeScript checker. Worth a tracking issue if this matters for ongoing crypto polyfill work.

CI

26 of 38 relevant test unit / test node_compat / wpt / lint debug shards SUCCESS at this head, with 12 still in flight (macos-aarch64 debug + linux-aarch64 debug + lint debug macos-x86_64 — the slower runners). No failures yet. Given the #33760 precedent had a V8 abort that surfaced only after the build/lint shards had passed, holding COMMENT until the remaining macOS / linux-aarch64 runs land green — particularly the test unit shards which exercised the OffscreenCanvas bug last time. Substance is fine from my side; if the in-flight shards come back clean, this is APPROVE-ready.

LGTM. The force-pushed delta is the same lazy_loaded_js conversion I walked previously; substance still tracks the established #33760 / #33779 / #33780 pattern, and the CI signal that was in-flight on my prior pass has now landed clean across the platforms that mattered for the OffscreenCanvas-style hazard:

• All 12 test unit_node shards pass — the canary for 00_crypto.js consumers like internal/crypto/keys.ts and crypto.ts that now go through core.loadExtScript.
• All 12 test unit shards pass — Web Crypto + CacheStorage globals from 98_global_scope_shared.js.
• All 36 test node_compat shards pass (3 shards × 6 platforms × 2 modes) — broadest signal that the internals.kKeyObject bridge resolves correctly across node:crypto entry paths.
• 11 of 12 test specs shards pass. The lone failure is test specs (2/2) debug macos-aarch64 cancelled at 30m19s — the 30-minute timeout, not a substantive failure. specs (1/2) on the same host passed in 5m30s, and every other macos-aarch64 shard (build / lint / integration / unit / unit_node / node_compat) succeeded. Same flake pattern that hit #33780.

Load-order coupling

The one substance question I left open in my prior pass — does internals.kKeyObject resolve when 00_crypto.js IIFE evaluates from 98_global_scope_shared.js? — checks out by chasing the import graph:

• 98_global_scope_shared.js ESM imports include import process from "node:process".
• ext/node/polyfills/process.ts:50 imports node:assert.
• ext/node/polyfills/assert.ts:21 imports internal/util/comparisons.ts.
• ext/node/polyfills/internal/util/comparisons.ts:35 imports internal/crypto/constants.ts for kKeyObject.
• internal/crypto/constants.ts (new in this PR) does internals.kKeyObject = kKeyObject; at module evaluation.

V8 module-evaluation contract: imports run before body. So by the time 98_global_scope_shared.js's body executes the core.loadExtScript("ext:deno_crypto/00_crypto.js") call, the entire process → assert → comparisons → constants chain has already evaluated and internals.kKeyObject is set. The destructure inside the crypto IIFE (const { kKeyObject } = internals;) gets the proper Symbol, not undefined.

The coupling is implicit but real, and worth the doc comment I flagged previously in constants.ts ("published for ext/crypto's lazy-loaded script"). If a future refactor drops the node:assert import chain from process.ts, kKeyObject silently becomes undefined and key[kKeyObject] writes go to property "undefined". Not a blocker for this PR; flagging for a follow-up doc tweak.

Pattern parity check

Bridge pattern matches the established convention from prior PRs in this series:

The cache bridges are explicit at the call site (read order obvious). The crypto bridge is implicit through the eager-import chain (acceptable, documented above). All four use the internals.* namespace consistent with prior precedent.

Not blocking on the macOS specs flake — pre-existing infrastructure, not introduced by this PR.

LGTM — re-affirming after the rebase. Substance is unchanged in shape but cleaner than the version I approved at 24b11772:

The internals.__fetchRequest / __fetchResponse / __fetchHeaders bridges I walked previously are gone. Now that #33784's ext/fetch lazy_loaded conversion has landed on main, 01_cache.js resolves its cross-extension dependencies directly via core.loadExtScript("ext:deno_fetch/23_request.js") etc., the same pattern every other lazy-loaded script uses. The bridge hack was always a workaround for ext/fetch still being ESM at the time; now there's no need.

What I re-verified at this head:

• ext/cache/01_cache.js uses core.loadExtScript for Request/RequestPrototype/toInnerRequest, toInnerResponse, getHeader — direct calls, no internals.__* bridge. ✓
• 98_global_scope_shared.js has zero internals.__fetch* writes — the bridge plumbing the prior version added has been excised. The body just calls core.loadExtScript for each dep. ✓
• internals.kKeyObject bridge for ext/crypto → ext/node still in place, since ext:deno_node/internal/crypto/constants.ts is still ESM (not lazy_loaded). The same load-order analysis from my prior review still holds: node:process → node:assert → internal/util/comparisons → internal/crypto/constants.ts runs as part of 98_global_scope_shared.js's ESM imports, before its body's core.loadExtScript("ext:deno_crypto/00_crypto.js") evaluates the IIFE. So internals.kKeyObject is set when crypto's IIFE reads it.
• Same 11 files, same conversion shape, same JS consumers updated to core.loadExtScript (ext/node/polyfills/crypto.ts, internal/crypto/keys.ts, runtime/js/90_deno_ns.js).

CI

123 pass, 1 pending, 1 skip, 0 fail at this head. The pending shard is the slower macos-aarch64 specs runner — same flake-prone shard that hit my prior review's pass too. All other shards across linux/macos/windows × x86_64 × debug+release pass.

Nothing else to add — this is a strict improvement over the version I previously approved.