Fix MultiMapAsync disposing the reader before unbuffered results are enumerated

[jinseojang0903]

Fixes #2099.

Problem

When calling any multi-map QueryAsync overload (e.g. QueryAsync<TFirst, TSecond, TReturn> or the Type[]-based QueryAsync<TReturn>)
with buffered: false, enumerating the returned sequence throws once the reader has already been disposed:

System.InvalidOperationException: Invalid attempt to call FieldCount when reader is closed.
at Dapper.SqlMapper.GetColumnHash(...)
at Dapper.SqlMapper.MultiMapImpl[...]+MoveNext()

Root cause

Both MultiMapAsync<TFirst,...,TSeventh,TReturn> and MultiMapAsync<TReturn> (Type[] overload) in SqlMapper.Async.cs wrapped the
DbDataReader in a using block. MultiMapImpl builds its result as a lazy, yield return-based IEnumerable<TReturn> that doesn't
start executing until the caller enumerates it. For buffered: false, the async method returns that un-enumerated sequence directly — so
the using disposes the reader immediately on return, before the caller ever gets a chance to read from it.

The single-type QueryAsync<T> path already avoids this by deferring disposal: it hands the reader into a small iterator
(ExecuteReaderSync) that only disposes it once the caller finishes enumerating. This PR applies the same pattern to both multi-map
overloads, adding a matching IEnumerable<TReturn>-based overload of ExecuteReaderSync for them to share.

Fix

• SqlMapper.Async.cs: transfer reader ownership into the deferred sequence instead of disposing it unconditionally when buffered: false.
• No change to the buffered: true path (already worked correctly, since .ToList() fully consumes the reader before the method returns).

Tests

Added two regression tests in AsyncTests.cs, following the existing TestMultiMapWithSplitAsync / TestMultiMapArbitraryWithSplitAsync
style:

• TestMultiMapWithSplitUnbufferedAsync
• TestMultiMapArbitraryWithSplitUnbufferedAsync

Both fail with the reported exception before this fix and pass after it. Full suite run locally (net8.0 + net10.0, SQL
Server/MySQL/Postgres) with no regressions.

[fathiaomar]

Left a question on line 950 regarding reader disposal and potential connection leaks during partial iteration

[fathiaomar]

Setting reader = null prevents immediate disposal so unbuffered results can be streamed, but if the caller abandons or partially enumerates the returned IEnumerable, the reader and underlying connection won't be closed. How are connection leaks handled if iteration stops early?

[jinseojang0903]

Thanks for the question! Early termination is covered: ExecuteReaderSync wraps the reader in a using inside an iterator, so the redder is disposed whenever the enumerator is disposed. That includes break or an exception inside a foreach, and LINQ operators like First(), Take() and Any(). If Dapper opened the connection itself, the reader is created with CommandBehavior.CloseConnection, so disposing the reader also closes the connection.

The only uncovered case is a caller who never enumerates the result, or who calls GetEnumerator() manually and never disposes it. That's the existing contract for buffered: false, and the single-type QueryAsync unbuffered path behaves the same way. This change follows that path exactly. Before this fix, the multi-map unbuffered path threw as soon as you enumerated it, so no new leak is introduced.