Fix type argument lost in constraint expressions within generic typea…

[adityabagchi24]

Description

When using a generic type alias with a constraint such as every((it) -> it is T), the type argument (for example, Int) was not being substituted into the constraint expression. As a result, the it is T check silently accepted any value instead of performing an actual type check.

Fixes #1705

Before

typealias MyList<T> = List(every((it) -> it is T))
foo: MyList<Int> = List("uhoh")  // accepted — incorrect

After

typealias MyList<T> = List(every((it) -> it is T))
foo: MyList<Int> = List("uhoh")  // rejected — correct

Root Cause

1. The lambda body inside constraint expressions (it is T) was stored without Truffle's @Child annotation. Consequently, the tree-walking logic responsible for substituting type parameters could not traverse into the lambda body.
2. The instantiation logic only replaced resolved type variable nodes. However, inside constraint expressions, the type variable still exists in its unresolved form when substitution occurs.

Fix

• Marked the lambda body expression as @Child so it can be properly traversed and deep-copied during type alias instantiation.
• Extended the instantiation logic to also handle unresolved type variables and replace them with concrete type arguments.
• Added a lightweight wrapper type that carries a pre-resolved type node into constraint expressions.

Validation

• List("uhoh") used as MyList<Int> now correctly produces a type constraint violation error.
• List(1, 2, 3) used as MyList<Int> continues to pass.
• Non-generic constrained type aliases (for example, typealias MyList = List(every((it) -> it is Int))) continue to work correctly.
• All existing LanguageSnippetTests, pkl-codegen-java, pkl-codegen-kotlin, and pkl-cli tests pass.