Fix {{fn}} with generic callbacks no longer inferring from the arg type

[BoussonKarel]

Fixes #1247

Since #1189, every {{fn f a}} compiles to a comma pair:

(resolve(fn)(f, a), bindPositional(f, a))

The fn call on the left has no contextual type. That's fine for most callbacks, but not for a generic one like <K extends keyof Person, V extends Person[K]>(key: K, value: V) => void: TypeScript needs the expected type to work out V. Without it, V falls back to string | number and valid code is rejected.

Fix

The comma pair is only needed in one place: inside the bindInvokable(...) half of {{component}} / {{helper}} / {{modifier}}, where a real fn call collapses inference (#1147). So now:

• Inside bindInvokable(...), fn becomes just bindPositional(...). The keyword call next to it already validates the arguments.
• Everywhere else, fn is a plain resolve(fn)(...) call again, like in ≤ 1.8.8, so it gets the expected type from its slot.

While in there: bindPositional's Bound is now const. Without that, a literal bound argument like "name" widened to string, and the result became never.

Tests

• New fn-generic-callback.test.gts with the repro from the issue, plus a mismatched callback that must still error
• The Issues with fn helper in combination with component helper #1147 guard (fn-in-nested-args.test.gts) and globals/fn.gts still pass unchanged
• Transform snapshots updated, plus a new one for fn inside a bind-invokable keyword

Not fixed here

(component Field onChange=(fn this.update "name")) with the same generic callback still errors, and a mismatched fn bind inside (component ...) on a generic component isn't caught. Both behave the same on main, so they aren't regressions. The keyword's own validation call doesn't give fn a useful expected type there. That's probably worth a separate issue.

🤖 Generated with Claude Code

[NullVoxPopuli]

tyty