Evaluate yield in computed public class field names

[frostney]

Summary

Class public fields with computed property names should correctly evaluate and resume yield expressions in the computed key expression.

Why

The --compat-while-loops test262 run now reaches generator bodies that previously no-oped at the outer while, exposing a shared interpreter/bytecode gap in class-field computed-name semantics.

Blocked test262 tests:

• language/expressions/class/cpn-class-expr-fields-computed-property-name-from-yield-expression.js
• language/expressions/class/cpn-class-expr-fields-methods-computed-property-name-from-yield-expression.js
• language/statements/class/cpn-class-decl-fields-computed-property-name-from-yield-expression.js
• language/statements/class/cpn-class-decl-fields-methods-computed-property-name-from-yield-expression.js

Current behavior

The class method/accessor computed-name variants pass, and object-literal computed names from yield pass. The class field variants fail in both interpreter and bytecode mode.

A reduced bytecode repro currently completes without yielding the expected key values and installs no field values:

function* g() {
  let C = class {
    [yield 9] = 9;
    static [yield 9] = 9;
  };
  let c = new C();
  console.log(c[9], C[9]);
}
const iter = g();
while (iter.next().done === false) ;

Observed test262 failures include Goccia VM throw, [object Object], or undefined is not a function depending on mode and field initializer shape.

Expected behavior

Computed names for public instance and static fields should follow ECMAScript class element evaluation semantics: the yield expression in the computed name suspends the generator, resumes with the supplied key value, and installs the field under that key.

Scope notes

Likely areas: parser/AST representation for computed class fields, class field evaluation in Goccia.Evaluator, and bytecode class-field lowering. This appears unrelated to while semantics; enabling while loops only makes the existing test262 generator drain loop run.