The byte data type is not supported by the IN clause

Intro

Looks like Dapper doesn't support byte data type in the IN clause.

Microsoft.Data.SqlClient.SqlException (0x80131904): Incorrect syntax near '@Types'.
   at Microsoft.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__195_0(Task`1 result)
   at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
   at Dapper.SqlMapper.QueryAsync[T](IDbConnection cnn, Type effectiveType, CommandDefinition command) in /_/Dapper/SqlMapper.Async.cs:line 434
   at X.Resource.Database.DatabaseClient.<>c__DisplayClass89_0`1.<<ListAsync>b__0>d.MoveNext() in /media/ramdisk/Platform/Src/Resources/Database/DatabaseClient.cs:line 190

Steps to reproduce

SQL query

select
  *
from
  [Underwriting]
where
  [LeadId] = @LeadId
  and [Type] in @Types;

C# code

// Working version
async Task<IReadOnlyList<UnderwritingDataModel>> ListAsync(int leadId, int[] types)
{
  return await ListAsync<UnderwritingDataModel>(UseSql("ListUnderwritings"), new { leadId, types });
}

// NOT working version
async Task<IReadOnlyList<UnderwritingDataModel>> ListAsync(int leadId, byte[] types)
{
  return await ListAsync<UnderwritingDataModel>(UseSql("ListUnderwritings"), new { leadId, types });
}

Dependencies

• Dapper 2.1.37
• Microsoft.Data.SqlClient 5.2.0
• .NET 8.0.3

Start by reproducing the SQL and C# examples against the listed Dapper, Microsoft.Data.SqlClient, and .NET versions. Then inspect Dapper's handling of collection parameters in IN clauses. Done means byte[] values work in the IN clause while the existing int[] behavior remains unchanged.