Isolate Database Contexts During External Leaderboard Requests

[STK0Cervanthes]

another cerv? :o again ramblings turned into coherent text by water guzzler john co pilot.

Summary

This PR separates the database contexts used by the external leaderboard flow from the context owned by LobbyManager.

The change is technically related to the recent database connection-exhaustion, but it is primarily a sanity and resource-lifetime cleanup. It should not be considered the primary fix for the incident. It should also be double checked if its actually smth yall want or nah its a sanity thing really not critical just making sure things get handled cleaner

Changes

• PostMatchResultAsync now receives an IDbContextFactory<AppDbContext> instead of a caller-owned AppDbContext.
• A short-lived context is used to load the match payload.
• That read context is disposed before the external HTTP request and retry sequence begins.
• A separate short-lived context is used for persisting returned ELO data.
• LobbyManager.DeleteLobby now passes the context factory instead of its active context.

Why

The external leaderboard request can involve retries and significant delays. Keeping the caller's DbContext in scope throughout that operation is unnecessary and makes resource ownership less clear.

Using independently scoped contexts ensures that:

• The HTTP retry path does not retain the caller's context.
• Database reads and writes have clear, limited lifetimes.
• Future changes to the external request flow are less likely to accidentally hold database resources across network operations.

Scope and Limitations

This change does not modify:

• The Strata/external leaderboard API contract.
• Retry delays or HTTP timeout settings.
• ELO calculations.
• Lobby behavior.
• The number of ELO updates performed.

EF normally returns the physical database connection to the ADO.NET pool after each completed command, so this change is not expected to be the sole resolution for connection-pool exhaustion.

one of the production issues identified separately is that the configured MySQL pool settings were being read but not applied to the connection string. That issue is addressed by the separate database pool configuration PR. --> #39

Validation

• dotnet build GenOnlineService/GenOnlineService.csproj
• Build succeeded with 0 warnings and 0 errors.

This one really aint all that important