## Summary

LiteLLM's spend tracking writes two categories of data per request: raw spend log rows (INSERTs into `LiteLLM_SpendLogs`) and entity-level spend counter increments (UPDATEs to key, user, end_user, team, team_member, org, agent, and tag tables via `_batch_database_updates`). At high request throughput the entity counter UPDATEs become the dominant source of DB write contention, deadlocks, and tail latency spikes.

There are two existing kill-switches. `disable_spend_updates` suppresses both raw logs and entity counter updates. `disable_spend_logs` suppresses only raw log writes but preserves entity counter updates. There is no flag that does the inverse: preserve audit-quality raw spend logs while suppressing only the entity counter UPDATE traffic.

Operators running multi-tenant deployments at 500+ RPS need raw spend logs for billing reconciliation and audit but cannot sustain the entity counter UPDATE throughput on their PostgreSQL instances. Without this escape hatch, they must choose between full spend-tracking (DB overload) or no spend-tracking at all (billing gaps).

## Proposed fix

Add `disable_entity_spend_updates: true` to `general_settings`. This gates the sch…