regression: #6541 store-plan cache sharing re-breaks bundled zod (#6530 repros fail again) — Next.js standalone down on main

[proggeramlug]

Summary

git bisect (automated, endpoints verified) pins a regression of the #6530/#6537 bundled-zod fixes to:

3306fde1f — perf(runtime): share the store-plan cache with receiver-based [[Set]] (#6541)

Parent 23bcda3eb (#6539 get/set fast lanes) passes; #6541 fails. Deterministic, PERRY_NO_AUTO_OPTIMIZE=1, clean object cache.

Repro (the #6530 regression suite, next/dist/compiled/zod/index.cjs copied locally)

const z = require("./zodlocal.cjs").z;
z.string().optional().parse(undefined);
// #6541: TypeError: Cannot read properties of undefined (reading 'errorMap')
// parent / node: returns undefined

z.record(z.string(), z.object({ p: z.string(), q: z.boolean().optional() })).parse({ a: { p: "x" } });
// #6541: TypeError: Cannot read properties of undefined (reading '_getType')
// parent / node: { a: { p: "x" } }

Simple cases (record(string,boolean).parse, object.parse, optional creation) still pass — same failure surface as the original #6530.

Impact

Re-blocks Next.js standalone serving at boot/request time (config-schema.js init reads through the same shapes): the gscmaster app on current main dies with Cannot read properties of undefined (reading 'description') again, undoing the #6537 progress. Field WRITES from zod's capture-class constructors appear to land where subsequent reads can't find them once the receiver-based [[Set]] shares the store-plan cache — plausibly the plan is keyed without whatever distinguishes the #6530-family capture-class instances (per-evaluation class objects / appended cap params), so a plan learned on one shape mis-stores on another.

Suggested check

The #6530 regression tests (test_gap_6530_* if present / the zod gap tests from #6537) against #6541's merge — and whether the store-plan cache key includes the capture-class discriminator that #6537 introduced.