Related: #916, #915. Parent: #899.
Confirmed on 92043c5-equivalent production binaries in forced tree-walker and VM modes: class C { static x = eval("new.target"); } throws SyntaxError instead of initializing x to undefined. The same failure occurs through immediate/escaped arrows and a static private field. A 13-case differential against actual system JSC gives 9/13 agreement in both modes; all four mismatches are these static-field cases. Instance fields, fields nested inside a constructor, computed-name scope, indirect eval rejection, and caller restoration controls agree.
Root cause: evalClass marks static field initialization with in_field_initializer, but leaves direct_eval_new_target_allowed inherited from the outer context. At global scope it remains false. The equivalent constructor scope happens to supply true, making acceptance incorrectly depend on where the class is defined. Arrow closures capture the same false permission.
ECMA-262 ClassFieldDefinitionEvaluation creates a non-lexical initializer function, and DefineField calls it. The initializer therefore has a new.target binding whose value is undefined. The existing in_field_initializer value masking already supplies undefined; the missing permission must be scoped and restored on success/throw, without leaking into computed keys or indirect eval.
Acceptance: regression tests across both tiers for public/private fields, direct/nested eval, escaped arrows, and normal/abrupt context restoration; preserve existing super()/arguments initializer restrictions; targeted class/eval corpus with exact denominators. No global admission relaxation or workaround.