regression(hir): natively-compiled cli.js throws nameless "identifier is not defined" at init — new <minified-local>() scope-resolution miss #8730

Summary

After #8724 (captured ArrayBuffer/DataView) is applied, the natively-compiled Claude Code cli.js 2.1.112 bundle still throws at module init on nearly every command (only --version escapes via early exit):

Uncaught (in promise) ReferenceError: identifier is not defined

Node runs the same bundle fine. The message is the nameless form (js_throw_reference_error_unresolved_get, error.rs:1013) — emitted by lower/expr_new.rs:1580 for new <X>() when X resolves to no lexical / function / class / import / native-module / reified-global-builtin binding. So some new X(...) at module-init has an X perry failed to resolve.

Lead

new $(...) appears 5× in the bundle, and $ is in the compile's "unknown identifier — assuming global" list. But $ is NOT an undefined global here — it's a pervasively-used minified local / parameter in cli.js (let $= ×1014, var $= ×240, ($)=>, function($), new $({type:"boolean"}), new $(this,h,C)). So perry's scope resolution is failing to bind $ to its definition in some new $() context and falling through to the unresolved-new throw. (Other unknown-list names — Bun/Deno/window/document/Iterator/AsyncIterator — are env/ES2025 globals; cli.js only reads them typeof-guarded or as strings, and Iterator is never used as a value, so they are not the blocker. new ReadableStream works — it's reified.)

To pin the exact identifier

Instrument the throw site and re-lower the bundle (the decision is in HIR lowering, before the slow LLVM codegen, so it can be captured in the first ~2 min):

// crates/perry-hir/src/lower/expr_new.rs, just before the NewDynamic throw return
eprintln!("[nameless-new] new {class_name}(...)");

Impact

Blocks running the natively-compiled Claude Code bundle end-to-end (startup). This surfaced only now because the bundle had not been run end-to-end on current main (the #8583 acceptance validated codegen completion, not a booting binary). Likely a perry scope-resolution gap for a class of minified identifiers, not a single-line fix.

Found while verifying #8707/#8726 against a freshly-built cc binary.