Give type-literal method members an implicit this param so annotated objects keep their receiver

[ASDAlexander77]

Summary

A type-literal annotation with a METHOD member (inc(): void, MethodSignature) mapped to a bare this-less FunctionType, unlike an inferred object literal (func<object<...>>) or an interface method (func<opaque,...>). Casting a method-bearing literal to such an annotation dropped the receiver ("losing this reference"), and calls through the annotated value passed garbage as this:

var counterObj: { count: number; inc(): void } =
    { count: 0, inc() { this.count = this.count + 1; } };
counterObj.inc(); counterObj.inc();
// counterObj.count stayed 0 - a wild write through garbage `this`

Fix (three parts)

• getTupleFieldInfo (MLIRGenTypes.cpp): MethodSignature members now get an implicit opaque this first param — the same convention already used for interface method funcTypes. isBoundReference then triggers on field access, binding the receiver from the base object, identical to how inferred object literals already behave.
• MLIRPrinter::printFuncType: skip an opaque/object-typed first input when printing function types — it's the implicit this, not declarable in source syntax ("Opaque" doesn't parse back), mirroring DeclarationPrinter::printParams which already omits this. Keeps the cross-module @dllimport declaration round-trip intact.
• CastLogicHelper: only warn "losing this reference" when the target FunctionType has no this slot of its own — a target that keeps the opaque this param loses nothing (the receiver is re-bound at each property access).

Test plan

New regression test 00object_annotated_method.ts (global + local annotated vars, mutating and reading methods), registered in both compile and jit modes.

Full ctest suite: 724/724 passed (722 existing + 2 new).

🤖 Generated with Claude Code