Native/WASM-query definitions order still diverges for object-literal methods nested in a class static block

[carlos-alm]

Summary

While fixing #1818 (native/WASM definitions array order divergence for the common case of a top-level const/let/var object-literal shorthand method), I found a narrower, pre-existing, unrelated variant of the same class of bug that #1818's fix does not (and should not, to stay scoped) touch.

Repro:

class Foo {
  static {
    const obj = { m() {} };
  }
}

Here obj's method m is nested inside a class static { } block. Because class_static_block is not itself a function-scope boundary, the const obj = { m() {} } is still treated as "top-level" for object-literal-method extraction, but m's method_definition node ALSO has an enclosing class (Foo), so the generic method handlers legitimately produce a class-qualified Foo.m entry (not a bare m) here — a different, correct-content shape than #1818's target case, and out of scope for its fix (confirmed: content is identical between native/WASM/walk, only order differs).

Native (matches WASM's manual walk path):

['Foo', 'Foo.<static:L:C>', 'obj', 'obj.m', 'Foo.m']

WASM query path (the actual path used in production when native is unavailable):

['Foo', 'Foo.m', 'obj', 'obj.m', 'Foo.<static:L:C>']

Foo.m's relative position differs between native and the production WASM query path (and, separately, WASM's own query path already disagrees with WASM's own walk path here too — a pre-existing internal WASM inconsistency).

Impact

Same class of impact as #1818: purely cosmetic array-order divergence, content (the set of {name, kind, line, endLine} tuples) is identical across all three extraction paths. Very rare shape (object literal with shorthand methods declared inside a class static { } initializer block) — much narrower than #1818's common top-level-const case.

Suggested fix

Once #1818 lands, apply the same root-cause fix (inline emission instead of a separate generic-vs-deferred pass) to this nested-class-static-block shape too, or — more simply — determine why WASM's query path and walk path disagree here in the first place (likely: the query path's meth_node capture fires unconditionally in file-position order regardless of nesting, while the walk-based extractConstantsWalk/runCollectorWalk split has different relative timing for class-body vs top-level-statement traversal) and align them.

Found while

Investigating and fixing #1818.