Fix: handle array / pointer / dynamic type arguments in nested constraint chains

[waynebrantley]

Summary

MatchedTypeSatisfiesConstraints in DependencyInjectionGenerator.FilterTypes.cs requires every candidate type argument in a nested constraint chain to be an INamedTypeSymbol. When the recursion reaches a constructed generic whose type argument is an array (T[], T[][]), pointer, or dynamic, the pattern-match fails and the whole handler is silently dropped from generation — no diagnostic, no warning.

Repro (fails on main)

using ServiceScan.SourceGenerator;

namespace Repro;

public static partial class Registrations
{
    [GenerateServiceRegistrations(AssignableTo = typeof(IHandler<,>), CustomHandler = nameof(AddHandler))]
    public static partial void AddHandlers();

    private static void AddHandler<THandler, TQuery, TResult>()
        where THandler : class, IHandler<TQuery, TResult>
        where TQuery   : class, IQuery<TResult>
    {
    }
}

public interface IQuery<T> { }
public interface IHandler<TQuery, TResult> where TQuery : IQuery<TResult> { }

public class BytesQuery       : IQuery<byte[]>   { }
public class JaggedBytesQuery : IQuery<byte[][]> { }
public class ScalarQuery      : IQuery<int>      { }

public class BytesHandler       : IHandler<BytesQuery,       byte[]>   { }
public class JaggedBytesHandler : IHandler<JaggedBytesQuery, byte[][]> { }
public class ScalarHandler      : IHandler<ScalarQuery,      int>      { }

Expected emit: all three AddHandler<...>() calls.
Actual emit: only AddHandler<ScalarHandler, ScalarQuery, int>(); — the two array-result handlers are silently dropped.

Root cause

MatchedTypeSatisfiesConstraints walks THandler's constraint chain recursively. On the outer step it matches THandler : IHandler<TQuery, TResult> fine. Then it recurses into TQuery : IQuery<TResult> by walking BytesQuery.AllInterfaces for IQuery<byte[]>. That step compares constraint type args with matched-interface type args:

if (matchedType.TypeArguments[i] is not INamedTypeSymbol candidateTypeArgument)
    return false;

matchedType.TypeArguments[0] = byte[] is an IArrayTypeSymbol, not INamedTypeSymbol, so the pattern-match fails and the whole outer handler is rejected.

Fix

Widen the check to ITypeSymbol and branch on shape:

• INamedTypeSymbol candidate → recurse into SatisfiesGenericConstraints as before.
• Other ITypeSymbol (array, pointer, dynamic) → can't recurse into nested constraints, but the simple constraints (class / struct / new() / interface / base-class) on the type parameter still apply. Reject struct, unmanaged, new(); honor class; and check interface / base-class constraint types against the candidate's AllInterfaces + BaseType.

Test

CustomHandlerTests.CustomHandler_HandlesArrayTypeArgumentInNestedConstraint covers byte[], byte[][], string[], and int. Verified: fails on main, passes with the fix; all 94 existing tests still pass.

Impact

Any consumer using CustomHandler (or ScanForTypes+Handler) with a nested-generic constraint chain and array-typed generic arguments — I hit it in production migrating a large CQRS codebase where IAsyncQueryHandler<Q, byte[]> handlers silently disappeared from DI after switching to source-gen.