fix(dynamic-import): resolve function/closure-local const string specifiers (#1725)

[proggeramlug]

Fixes #1725.

Problem

import { logger } from 'hono/logger' fails to compile under Perry-native because hono/dist/utils/color.js contains:

async function getColorEnabledAsync() {
  const cfWorkers = "cloudflare:workers";
  const isNoColor = navigator?.userAgent === "Cloudflare-Workers"
    ? await (async () => {
        try { return "NO_COLOR" in ((await import(cfWorkers)).env ?? {}); }
        catch { return false; }
      })()
    : !getColorEnabled();
  return !isNoColor;
}

cfWorkers is a function-local const string literal (captured into a nested IIFE), used as a dynamic import() specifier inside the classic optional-dep try/catch. Perry's compile-time const-folder (collect_module_const_locals) only collected module-level consts — on the now-incorrect assumption that a dynamic import always runs in module-init scope — so it rejected the local const with a hard error:

Error: dynamic import() in module .../color.js: path argument references a binding
that is not a module-level const initialized to a literal ...

Relationship to the dynamic-import series

This is a targeted slice of #1674 (the variable/non-literal specifier axis of the #1672/#1673/#1674 series). It is not the runtime-dispatch gap (#1672/#1673) — the specifier here is statically a string literal, just function-scoped. Fully-dynamic / computed specifiers remain #1674's scope.

Fix

Collect non-mutated const x = <init> bindings from the full scope set that for_each_dynamic_import_mut already walks — module init, every function / method / getter / setter / static-method body, and field + global initializers — descending into closure bodies. At this HIR stage closures are still inline and capture by the original LocalId, and the import walker descends into closure bodies, so a const declared in any enclosing scope now resolves at the import site. LocalIds are module-unique, so a single flat id → init map is unambiguous. The mutation-invalidation scan was extended symmetrically (it now also descends into closures) so a reassigned binding is still dropped.

cfWorkers then resolves to "cloudflare:workers", which has no module under Perry, so it rejects at runtime (a warning, not a compile error) — caught by the package's own try/catch, exactly matching Node's optional-dep behavior.

Validation

The #1725 acceptance program compiles and runs:

import { Hono } from 'hono'
import { logger } from 'hono/logger'
const app = new Hono()
app.use('*', logger())
app.get('/', (c) => c.text('ok'))

→ compiles (graceful Could not resolve import 'cloudflare:workers' warning), runs, app.use('*', logger()) works, routes register.

Tests

• resolve_closure_local_const_specifier — a const inside a closure body resolves as a specifier.
• collect_consts_invalidates_closure_mutation — a binding reassigned inside a closure is dropped (soundness).
• Existing resolve_unresolved_param_local / resolve_unresolvable_local still reject (no regression); full perry-hir lib suite green.