Unobserved null reference exception

### Describe the bug

About once or twice a week on production (using Azure SQL) we get an unobserved null reference exception.
I've run some analyzers on our code and there's not a single task that is not awaited.

Today we had a caught exception right before the unobserved one (`Microsoft.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired.`).

The stack trace doesn't indicate any code from us and it doesn't seem related to above (I traced all code paths to ensure its error indeed caught the exceptions).

```
System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. (Object reference not set to an instance of an object.)

---> System.NullReferenceException: Object reference not set to an instance of an object.

at Microsoft.Data.SqlClient.TdsParserStateObject.ReadAsyncCallback(IntPtr key, PacketHandle packet, UInt32 error)

at Microsoft.Data.SqlClient.TdsParserStateObject.ReadAsyncCallback(PacketHandle packet, UInt32 error)

at Microsoft.Data.SqlClient.ManagedSni.SniMarsHandle.HandleReceiveError(SniPacket packet)

at Microsoft.Data.SqlClient.ManagedSni.SniMarsConnection.HandleReceiveError(SniPacket packet)

at Microsoft.Data.SqlClient.ManagedSni.SniMarsConnection.HandleReceiveComplete(SniPacket packet, UInt32 sniErrorCode)

at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---

at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)

at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)

--- End of inner exception stack trace ---
```

### To reproduce

Not really any reproduction since it feels like there's nothing we're doing specifically, though maybe worth noting it relates to a relatively intense and regular SQL activity (we're using a `sp_getapplock` regulary inside this method).

Perhaps worth noting we're wrapping the SQL client with Dapper.

### Expected behavior
No unobserved task exceptions

### Further technical details
Microsoft.Data.SqlClient version: `6.1.2`
.NET target: `net9`
SQL Server version: Azure SQL
Operating system: Docker container running Ubuntu

**Additional context**
None, but happy to expose anything useful.

Similar to [#746](https://github.com/dotnet/SqlClient/issues/746)