### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate

### What happened?

With `general_settings.use_redis_transaction_buffer: true`, the leader pod removes buffered spend transactions from Redis before their database commit is acknowledged. If the database write fails after its retries, the removed spend is neither restored nor retried

The scalable path calls `get_all_transactions_from_redis_buffer_pipeline`, then commits each returned category to Postgres in [`_commit_spend_updates_to_db_with_redis`](https://github.com/BerriAI/litellm/blob/3f9b71c1a45e870d1789ee105bd59b9274bb0d74/litellm/proxy/db/db_spend_update_writer.py#L770-L878). The drain is a destructive `async_lpop_pipeline` across the entity and daily queues in [`RedisUpdateBuffer`](https://github.com/BerriAI/litellm/blob/3f9b71c1a45e870d1789ee105bd59b9274bb0d74/litellm/proxy/db/db_transaction_queue/redis_update_buffer.py#L464-L545)

The enclosing exception handler only emits `Data already popped from Redis may be lost` and releases the leader lock. There is no processing queue, acknowledgment, `LTRIM` after success, or requeue path for the popped payload

…