fix(leaderboards): move match publication to a durable background queue

[tintinhamans]

External leaderboard publication previously ran during lobby teardown on the WebSocket processing path. External HTTP latency and retries could therefore delay processing for connected users.

This change records publication work when a match is finalized and processes it asynchronously through a durable database-backed worker.

---

• Finalize match history and schedule external publication in the same database transaction.
• Persist publication attempts, retry time, last error, and completion time in external_publication.
• Publish pending matches from a background worker with persisted retry backoff.
• Stop retrying permanent client errors while retaining retries for transient failures.
• Keep EF Core contexts scoped to individual database operations; no context is held during external HTTP.
• Separate publication transport from persistence: the external client only sends the match and returns the response, while the worker owns database and session-cache updates.
• Save rating updates to the database before updating the local session cache.
• Treat rating-response processing as best effort so it cannot retry an already successful ingest.
• Remove Polly because retry state is now handled durably by the worker.

---

Apply upgrade_20260816_external_leaderboard_publication.sql before deploying the updated service.

The worker currently assumes a single service instance.

[STK0Cervanthes]

this would also solve #40 right?

[Skyaero42]

Removing polly is the correct call here I think.

I'm pretty new to the code base and style, so I'm still struggling a bit. Overall this looks good.

One point of attention: the new code throws at a few points. I'm not entirely sure if the throw is properly caught. If it is not, the timer will not be restarted and cleaning up the lobbies will fail.

[Skyaero42]

Not sure if you want to throw here.

Is it caught somewhere else?
Does it have to be thrown or can the application continue after it has been caught at this level?

Multiple times in this PR.

[tintinhamans]

This prevents the exception from being swallowed. It bubbles up to DeleteLobby, logs to Sentry, and returns false, so the lobby persists and the cleanup will retry.

[Skyaero42]

nit: name has 'get' twice. Recommend GetExternalLeaderboardsConfig

[tintinhamans]

I’ve renamed it :)

[Skyaero42]

This can throw and is not caught. Is that intentional?

[tintinhamans]

It’s handled by DeleteLobby, which logs the error and leaves the lobby registered so the cleanup timer can retry it.