Source-gen infers generic type arguments from a data source's declared type, so broad declared types fail constraints that the runtime value meets #7116

Summary

When a generic test method's data source is declared with a broad static type, source-generation mode infers the type argument from the declared type rather than from the runtime value. If that declared type does not satisfy the method's constraint, the test is dropped (or, once #7102 lands, reported as a constraint failure). Reflection mode infers from the runtime value, so the same test runs and passes.

Repro

public class BroadDeclaredTypeTests
{
    public static IEnumerable<Func<object>> Streams() => [() => new MemoryStream()];
    public static IEnumerable<Func<int?>> Numbers() => [() => 1];

    [Test]
    [MethodDataSource(nameof(Streams))]
    public void Disposable<T>(T value) where T : IDisposable { }

    [Test]
    [MethodDataSource(nameof(Numbers))]
    public void Comparable<T>(T value) where T : IComparable { }
}

• Reflection mode: both tests are discovered and pass (T = MemoryStream, T = int).
• Source-gen mode: the generator infers T = object / int?, the constraint check fails, and the tests are not run.

Notes

• Found while addressing review on fix(analyzers): TUnit0001 false positive for MethodDataSource on generic type-parameter parameters #7109 (TUnit0001). The analyzer keeps flagging this case, because in source-gen mode (the default, and always under AOT) TUnit0001 is the only signal the user gets.
• Related: Generic test rows that violate type constraints are silently dropped in source-gen mode but fail in reflection mode #7097, fix(engine): substitute class type arguments and array element types in build-time constraint checks #7102.
• Possible directions: make source-gen defer inference to the runtime value when the declared type is not exact (a non-sealed class, object or Nullable<T>), or document that source-gen infers from declared types and keep the analyzer error.