My immediate reaction is that 3% is a mighty small margin for error. I don't know exactly how max_slot_wal_keep_size is enforced these days, but in the past restrictions like that were implemented by deciding during a checkpoint whether to unlink a no-longer-needed WAL file (if we had too much WAL) or rename/recycle it to become a future WAL segment (if not). So you could overshoot the specified target by more or less the amount of WAL that could be emitted between two checkpoints. Perhaps it's tighter nowadays, but I really doubt that it's exact-to-the-kilobyte-at-all-times.
In this case, the total volume size was 60GB and we had the parameter set to 58GB but I imagine that can still be overwhelmed quickly. Maybe we should target a 20% buffer zone? We have wal_keep_size defaulted at 0.