Fixes#62812

Problem

When a union/intersection type likenumber | string appears in the true branch of a conditional type that has the same type as its check type, the type was incorrectly being narrowed with a substitution constraint. This caused issues when the union type was used as a type argument to a generic type.

For example:

typeCrossProduct<Union,Counterextendsunknown[]>=Counterextends[inferZero, ...inferRest]    ?(Unionextends inferMember        ?[Member, ...CrossProduct<Union,Rest>]        :never)    :[];typeDepth1=CrossProduct<number|string,[undefined]>// [string] | [number]// This works correctly:lettest2:(number|stringextends inferUnion ?(Unionextendsunknown ?[Union, ...Depth1]:never) :never);// Result: [string, string] | [number, number] | [string, number] | [number, string]// But this was broken (inlined instead of aliased):lettest3:(number|stringextends inferUnion ?(Unionextendsunknown ?[Union, ...CrossProduct<number|string,[undefined]>]:never) :never);// Expected: [string, string] | [number, number] | [string, number] | [number, string]// Actual: [string, string] | [number, number]  (missing cross-product entries)

Root Cause

IngetConditionalFlowTypeOfType, when processing a type node in the true branch of a conditional type, the function checks if the type matches the conditional's check type and creates a substitution type with the implied constraint.

The issue is that for structural types likenumber | string, different occurrences in the code all resolve to the same canonical type. So whenCrossProduct<number | string, [undefined]> appeared inside the true branch ofnumber | string extends infer Union ? ..., the type argumentnumber | string was incorrectly being narrowed with the constraintUnion even though it was a completely independent occurrence.

Fix

Added a check to skip this narrowing for union/intersection types that don't contain type variables:

constisStructuralTypeWithoutTypeVariables=!!(type.flags&TypeFlags.UnionOrIntersection)&&!couldContainTypeVariables(type);if(!isStructuralTypeWithoutTypeVariables&&(covariant||type.flags&TypeFlags.TypeVariable)&& ...){

This ensures:

• Named types (interfaces, classes, type aliases) still get narrowed - different references to the same named type refer to the same entity
• Structural types (unions, intersections) without type variables are NOT narrowed - different occurrences are independent even if they structurally match

Test

Addedtests/cases/conformance/types/spread/spreadTupleUnionDistribution.ts to verify the fix.