Fix cross-module multi-method vtable corruption via decl-text object-vs-tuple printing

[ASDAlexander77]

Summary

• A structurally-typed export's method fields are physically stored as plain FunctionType (a raw 8-byte function pointer — this/the object is implicit via the container). The cross-module declaration-text printer (MLIRPrinter.h) described named-field (object-shaped) types using positional tuple syntax ([name: (args) => result]) instead of object syntax ({name(args): result}), so method fields round-tripped on import as the wider HybridFunctionType (16-byte {data,func} pair) instead of matching the exporter's actual storage.
• This added a fixed +8-byte read-offset drift per method field on reimport: the first method field happened to still read correctly, the second read a plausible-looking wrong value, and the third read past the end of the real object entirely — crashing on a null function pointer call when casting a genuinely multi-method structurally-typed cross-module value to an interface.
• Fix: printType's dispatch for TupleType/ConstTupleType/ObjectStorageType now calls printObjectType (method-signature-friendly) instead of printTupleType whenever every field has a real id (i.e. the type is object-shaped, not a positional tuple) — matching the pre-existing diagnosis already documented in printFields's own comment, just not previously wired up.

Test plan

• New regression test export/import_object_literal_structural_typed_multi_method.ts (3-method interface add/addTwice/scaled), both test-compile-shared-... and test-jit-shared-... variants — verifies correct values end-to-end (3/7/14) where it previously crashed on the third method
• Full 734-test suite: 100% pass, no regressions
• Updated docs/interface-vtable-simplification-design.md to record the real root cause (the design doc's earlier "candidates worth checking" — vtable-patch-loop ordering, undersized heap clone — were both ruled out; this bug was upstream of that code entirely)

🤖 Generated with Claude Code