Connection pool exhaustion with EF Core DbContext connection lifetime

Understanding when EF Core acquires and releases a physical database connection relative to DbContext lifetime and per-command execution is needed to reason about intermittent pool exhaustion. The documented interaction between DbContext connection management, SaveChanges and provider pooling is relevant, as is the effect of holding a DbContext instance across asynchronous boundaries.

The Microsoft.EntityFrameworkCore.Database.Connection logging category documents connection acquisition and release events. Provider pools such as Microsoft.Data.SqlClient maintain their own limits, and EF Core command interception can influence how long a connection remains checked out. The precise conditions under which a new connection is opened for each SaveChanges versus reused within a single DbContext lifetime are not fully clear.

Does EF Core guarantee release of the physical connection after each command when the DbContext remains undisposed? How does the CloseConnection option interact with provider pooling across async await points? What observable signals distinguish EF Core connection management from underlying ADO.NET pool exhaustion?