Fix object literals silently corrupting data with interleaved field/method type annotations

[ASDAlexander77]

Summary

• An object literal's own internal storage always lays out as "all fields, then all methods" — mlirGenObjectLiteralFields/mlirGenObjectLiteralMethodPrototypes run as two separate passes over the literal's properties, by design (a method may reference sibling fields that must already be registered).
• A type-literal annotation on the receiving var/let, however, preserves verbatim interleaved source declaration order.
• When these orderings diverge — any annotation with 2+ fields and 2+ methods not grouped fields-first — method bodies get compiled against the WRONG byte offsets relative to the annotated variable's actual memory layout. A this.field write can silently land on a neighboring method's function-pointer slot instead of the intended field. No compile error, no crash — just silently corrupted data.
• Minimal repro:

  var raw: { base: number; addBase(n: number): void; total: number; add(n: number): void; } = {
      base: 100.0,
      addBase(n: number) { this.base = this.base + n; },
      total: 0.0,
      add(n: number) { this.total = this.total + n; },
  };
  raw.add(3);
  print(raw.total); // printed 0 before this fix, should print 3

Fix

After all fields/methods/captures are processed but before method bodies are generated, if the receiver type's field order differs from the literal's own accumulated order, permute the literal's field list (and the parallel value list) to match it. Field access inside method bodies resolves by name against the storage type's live field list at codegen time, so this reordering alone is sufficient — no per-method index patching needed.

Test plan

• Minimal repro and 7 bisection variants re-verified manually: all correct
• New same-module regression test 00object_annotated_method_interleaved.ts (compile + JIT)
• New cross-module regression test export/import_object_literal_structural_typed_interleaved.ts (compile + JIT), combining this fix with the recent decl-text printer fix (Fix cross-module multi-method vtable corruption via decl-text object-vs-tuple printing #263)
• Full 738-test suite (734 existing + 4 new): 100% pass, no regressions

Known follow-up (not in scope here)

An extends-based variant of the cross-module scenario (interface Base {...} interface Accumulator extends Base {...}, cast in the importer) still fails to compile at all with a bare error: failed statement — confirmed unrelated to this bug (the flat, non-extends version with identical members now compiles and runs correctly). Looks related to a separately-documented discovery-pass issue; not investigated further here.

🤖 Generated with Claude Code