Generic class with a class [Arguments] row that infers no type argument: modes disagree on T and constructor values, source-gen drops [Arguments(null)] #7209

What happens

A generic test class has a class-level [Arguments] row whose values go to constructor parameters that are not type parameters. Source-generated mode and reflection mode then choose different instantiations and constructor arguments, and source-generated mode drops an [Arguments(null)] method row.

[Arguments(42)]
public class Probe<T>(int number)
{
    [Test]
    [Arguments(null)]
    [Arguments(1)]
    public async Task Run(T value) =>
        await Assert.That($"T={typeof(T).Name} number={number}").IsEqualTo("show");
}

Observed on the fix/issue-7141-null-row-generic-class branch (PR #7203, based on main at c4b9977), net10.0, filter /*/TUnit.TestProject.Bugs._7141/Probe*/*:

Expected

Both modes should agree, and no row should vanish. A class row whose values map to no type parameter supplies no class type argument. In that case T should come from the method rows, as it does without a class row: C<int> for [Arguments(1)] and C<object> for [Arguments(null)] (#7141). The instance should be constructed from the class row (number=42).

Where

• Source gen: TestMetadataGenerator.GetConcreteInstantiations sets classTypeArgumentsSupplied by attribute presence. So nullArgumentsArrayInfersObject is false even when the class row infers nothing, and the null row is dropped. Instance creation for a method-row-inferred instantiation bakes in the method row's values (Generic class: source-gen builds the instance from a method [Arguments] row when class types come from a class-level data source or [GenerateGenericTest]; reflection uses the class data #7161, being fixed in PR fix(generic): build generic class instances from class data, never from method rows #7192).
• Reflection: class-row grouping infers T from a class row value that is not passed to a T parameter.

This came up in review of PR #7203 (#7203 (comment)). It should be fixed after #7149 and #7192 merge, because they rework the class-row and method-row pairing and instance construction for exactly this shape.