Tracker: AOT-first eval/new Function strategy — evaporate runtime dynamism at build time

[proggeramlug]

Goal

Make Perry handle eval / new Function the way an AOT compiler should: never execute a code-string at runtime. Every legitimate case is resolved at or before build time, so the runtime JS engine (perry-jsruntime / embedded V8) becomes deletable from shipped binaries.

What the investigation found (verified against vendored sources)

• eval is already dead in Perry-emitted code (perry-hir/src/lockdown.rs: "Perry doesn't emit eval today"; new Function(body) already refused in perry-hir/.../expr_call/intrinsics.rs). Zero test-files use either.
• Effect / Zod use no eval/new Function. Zod grep is clean; Effect's Schema is a combinator interpreter over an AST. The Effect blocker is purely compiler-completeness (perry-codegen: Effect — (number).slice is not a function during Schema.ts__init (#680 follow-up, ~310th init) #684 / perry-codegen: object literal with computed-key props + computed-key methods + cross-module spread drops keys & mis-resolves methods — Effect HashRing.ts blocker (post-#740) #809), not dynamism.
• The real new Function corpus is small and Fastify-shaped. Runtime libraries that actually JIT: fast-json-stringify (new Function('validator','serializer', contextFunctionCode) from a build-time schema), ajv (schema → validator), find-my-way (registered routes → matcher). Everything else that matched is build tooling (vite/rollup/next/eslint/vitest) that never ships in a Perry binary, or trivial feature-probes.
• Every legitimate case specializes a function from build-time-knowable config — a schema, a route table — not from genuinely-runtime data.

Conclusion: a runtime interpreter ("PerryVM") has no use case here. The only place an evaluator is needed is build time, and we already own one (V8) — so the move is to demote V8 to a build-time tool, not embed it at runtime.

Phases (strictly gated)

Each phase must be merged to main and parity-green before the next is started. No parallel work across phases.

• Phase 0 — classifier + precise refusal diagnostic: feat(codegen): classify new Function/eval call sites + precise refusal diagnostic #1678
• Phase 1 — const-fold literal new Function bodies → native: feat(codegen): const-fold literal new Function bodies to native functions #1679
• Phase 2 — build-time codegen convention (ajv/standalone first): feat(tooling): build-time codegen convention — ajv/standalone (+Prisma/Drizzle/Vue) AOT path #1680
• Phase 3 — build-time evaluation of runtime codegen (demote V8 to build-time tool): feat(tooling): build-time evaluation of runtime codegen — demote perry-jsruntime to a build-time tool #1681
• Phase 4 — Perry-native reimplementation of imperative-runtime JIT libs (find-my-way): feat(stdlib): Perry-native reimplementation of imperative-runtime JIT libs (find-my-way router) #1682

End state

A Perry binary that links no runtime JS engine, where:

1. constant code-strings became native functions (P1),
2. schema/template codegen libraries ran at build time and emitted native code (P2/P3),
3. the few imperative-runtime JITs have native equivalents (P4),
4. anything left over is a clear compile error naming the package and call site (P0).