perf: lazy-load FFI, KV, cron, signals, and fs_events modules

[bartlomieju]

Summary

Move rarely-used Deno API modules from eager evaluation to lazy loading using the existing createLazyLoader/propWritableLazyLoaded pattern (same as WebGPU and QUIC). These modules are now only evaluated when their APIs are first accessed, reducing snapshot heap size.

Lazy-loaded modules:

• ext:deno_ffi/00_ffi.js — Deno.dlopen, UnsafeCallback, UnsafePointer, UnsafePointerView, UnsafeFnPointer
• ext:deno_kv/01_db.ts — Deno.openKv, Kv, KvU64, KvListIterator, AtomicOperation
• ext:deno_cron/01_cron.ts — Deno.cron
• ext:deno_os/40_signals.js — Deno.addSignalListener, Deno.removeSignalListener
• ext:runtime/40_fs_events.js — Deno.watchFs

Impact: ~430 fewer V8 objects deserialized at startup, ~51 fewer functions in the snapshot. Modest for these small modules, but establishes the pattern for larger lazy-loading efforts (node compat layer via import defer).

Context

Profiling showed Deno deserializes 84,780 V8 objects at startup vs Node's 26,326 (3.2x). The bulk comes from eagerly evaluating all polyfill modules. This PR applies lazy loading to the low-hanging fruit — modules that are rarely needed at startup. The larger reduction will come from deferring the node compat layer once import defer support lands (#32360).

Test plan

• deno run, deno eval work correctly
• Deno.watchFs works (lazy-loaded on access)
• Deno.addSignalListener works (lazy-loaded on access)
• Build succeeds with snapshot creation

🤖 Generated with Claude Code

[bartlomieju]

Not worth complexity for now