### Check for existing issues

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

### What happened?

This issue was previously identified and attempted to be fixed in PR #23452 . We are silently losing spend tracking data, which makes billing and usage metrics unreliable. The bug still exists. I copy/pasted the description below:

## Summary

`_update_daily_spend()` only processes the first 100 transactions per flush cycle and silently discards the rest. Under any workload that produces more than 100 unique `(entity_id, date, api_key, model, provider, endpoint)` combinations between flush intervals (~10s), spend data is permanently lost from all Daily Spend tables.

This affects `LiteLLM_DailyTagSpend`, `LiteLLM_DailyUserSpend`, `LiteLLM_DailyTeamSpend`, `LiteLLM_DailyOrgSpend`, `LiteLLM_DailyEndUserSpend`, and `LiteLLM_DailyAgentSpend`.

## Root cause

In `_update_daily_spend()` (`db_spend_update_writer.py`), the retry loop processes only the first `BATCH_SIZE=100` sorted entries, then `break`s:

```python for i in range(n_retry_times + 1): # retry loop transactions_to_process = dict( sorted(daily_spend_transactions.items…