fix(hir): #1001 — restore built-in static identity in member position (regression from #973)

[proggeramlug]

Fixes #1001.

Problem

Number.parseFloat === parseFloat and Number.parseInt === parseInt evaluated to false (Node/spec: true). More broadly, any built-in wrapper-constructor static accessed as a member value (Number.*, Object.*, Array.*, String.*, …) lost identity with its intrinsic global. This regressed the pre-existing core gap test test-files/test_gap_number_math.ts against node --experimental-strip-types.

Root cause (bisected on Windows)

Introduced by 5ddccbbc — feat(runtime): .constructor property on Date/Array/Object instances (#973).

Commit	Number.parseFloat === parseFloat
7586a920 (#968)	✅ true
43cd9ffe (#970)	✅ true
5ddccbbc (#973)	❌ false
94d419f1 (#975) … current 17e99ea7	❌ false

#973 added an HIR lowering arm (is_builtin_global_value_name in crates/perry-hir/src/lower.rs) that rewrites bare built-in identifiers used as values to PropertyGet { GlobalGet(0), name }, so identity checks like inst.constructor === Date resolve both sides to the same populate_global_this_builtins closure. That intent is correct. The bug: the rewrite also fired when the built-in ident was the object of a member access, so Number.parseFloat became globalThis.Number.parseFloat rather than the intrinsic static — no longer the same value as the intrinsic global parseFloat.

Fix

crates/perry-hir/src/lower/expr_member.rs: after lowering the member object, detect the case where #973's reroute fired on a member-object built-in ident and revert that object to the intrinsic Expr::GlobalGet(0) (pre-#973 behavior). Strictly limited to member-object position, so #973's bare-ident-as-value feature is untouched. Local shadowing is inherently safe — a shadowing local lowers to LocalGet and never reaches this reroute.

Validation

• Number.parseFloat === parseFloat / parseInt → true
• test_gap_number_math byte-identical to the known-good v0.5.969 / Node output
• feat(runtime): .constructor on Date/Array/Object instances #973's own test_constructor_property.ts (.constructor === Date/Array/Object) still fully passes
• Builtin-heavy compile+run sweep green (Object.keys, Array.isArray, String.fromCharCode, Number.* statics as values and calls)

Out of scope

const f = Number.parseFloat; f(x) throws TypeError: value is not a function — a separate, pre-existing limitation (fails identically on pre-#973 v0.5.969), not addressed here.