fix(#957 followup): Function('return this')() + bare RegExp(...) recognisers

[proggeramlug]

Summary

Closes two distinct module-init holes flagged in PR #959's commit message ("the next runtime gap") that kept real lodash throwing TypeError: value is not a function at <anonymous> before any user code ran.

• Function('return this')() — the canonical "give me globalThis" idiom every CJS/UMD library copies (lodash.js:436, also underscore + Effect prelude). Bare Function lowers to Expr::GlobalGet(0) (no-resolution sentinel), so the inner call dispatches through js_closure_call1 on a null closure handle and throw_not_callable fires with the hardcoded b"value" property name — hence the line-less TypeError: value is not a function. AST-match the two-call shape at HIR lower time and fold to a new Expr::GlobalThisExpr variant that lowers to js_get_global_this() — the same lazy singleton globalThis[X] = V already writes to (perry-runtime: Effect framework SIGSEGVs during Utils.ts module init — array-fast-path called with x0 = 0x1 (Effect end-to-end blocker, post-#592) #611).

• RegExp(pattern[, flags]) bare function call + new RegExp(<non-literal>) — lodash builds ~6 of these at module init (e.g. var reHasEscapedHtml = RegExp(reEscapedHtml.source);). Both hit the same null-callee path because RegExp lowered identically to Function. Fold both to a new Expr::RegExpDynamic { pattern, flags } that lowers to the existing js_regexp_new(pattern, flags) runtime entry — the same entry the static /foo/g arm uses. Missing flags fall back to interning the empty string at codegen so js_regexp_new always sees a real StringHeader*.

Test plan

• New regression test-files/test_lodash_function_return_this_regexp.ts (12 assertions, byte-for-byte match with node --experimental-strip-types):
  • Function('return this')() identity + write-then-read through the singleton
  • Whitespace + trailing-semicolon variants of the inner literal
  • RegExp(literal) / RegExp(literal, 'g') / RegExp(varPattern) / RegExp(/foo/.source) (the literal lodash shape)
  • new RegExp(varPattern[, varFlags]) (the previously-broken dynamic-arg new form)
  • new RegExp(literal) (regression guard for the path that already worked)
• test-files/test_regex.ts parity unchanged (20/20 lines match node)
• cargo build --release -p perry-runtime -p perry-stdlib -p perry green
• cargo fmt --all clean

Known follow-up

import _ from "lodash" no longer throws at IIFE init — module.exports = _ propagates correctly. Real lodash still hits a separate compat gap further inside runInContext(): var Array = context.Array reads undefined because the empty globalThis singleton doesn't expose JS built-in constructors as properties, and the subsequent Array.prototype throws Cannot read properties of undefined (reading 'prototype'). Tracked separately — this PR is the IIFE-init slice (the bug PR #959 explicitly flagged); the globalThis.Array === Array work is its own architectural change. The other tier3 sweep failure (debug package silent — process.stderr is undefined under perry) is independent of these recognizers and out of scope here.

🤖 Generated with Claude Code