Reuse a single Redis connection in records_lib::mappack::calc_scores

[Copilot]

After the deadpool 0.12.3 upgrade reduced default pool capacity, concurrent handlers that check out Redis twice in one request could starve the pool and block unrelated Redis-backed endpoints. This PR makes pool behavior explicit and removes the deadlock-prone checkout pattern in the affected handler.

Redis pool config is now explicit and stable

Set fixed Redis pool size to 16 (instead of relying on upstream defaults).
Added a pool wait timeout of 2s for connection checkout to fail fast under saturation instead of waiting indefinitely.
Removed double-checkout pattern in player_finished

Refactored the handler to reuse the already-checked-out Redis connection for the pipeline/rank update path.
Eliminates the “hold one connection, wait for another” deadlock scenario under concurrent load.
Focused guardrail test

Added a unit test around pool config construction to assert:
max_size == 16
wait timeout == 2s

Moreover, calc_scores was checking out Redis twice in one function scope, and the second binding shadowed the first, keeping two pooled connections alive concurrently. This change keeps a single connection for the full function path.

• Problem

  • calc_scores acquired one Redis connection for mappack membership/expiry handling, then acquired another for rank lookups in the map loop.

• Change

  • Removed the second redis_pool.get().await? in calc_scores.
  • Reused the existing redis_conn for subsequent ranks::get_rank(...) calls.

• Effect

  • Eliminates unnecessary concurrent pool checkout in this path.
  • Keeps connection lifetime explicit and consistent through the function.

let mut redis_conn = redis_pool.get().await?;

// ... read mappack_uids / expiry handling ...

for (i, map) in mappack.iter().enumerate() {
    // ...
    let record = RankedRecordRow {
        rank: ranks::get_rank(&mut redis_conn, map.id, record.record.time, event).await?,
        record,
    };
}