### Check for existing issues

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

### The Feature

## Proposal

Allow the partition management path (`ensure_partitions` / `drop_partitions_older_than`) to run with `lock_timeout` and `statement_timeout` applied — scoped only to those DDL statements, so no other queries are affected. Sensible would be exposing them as env vars (or `general_settings` keys) with conservative defaults such as `lock_timeout=3s`, `statement_timeout=5s`.

### Motivation, pitch

## What happened in production

We run `vacuumdb --freeze` as a nightly cron on our Postgres cluster — standard practice to prevent transaction ID wraparound. On one night, `vacuumdb --freeze` on `LiteLLM_SpendLogs` overlapped with the litellm partition cleanup tick.

Timeline: 1. `vacuumdb --freeze` starts, holds `ShareUpdateExclusiveLock` on `LiteLLM_SpendLogs` for the duration of the freeze pass. 2. litellm's `SpendLogsPartitionManager` fires and issues `DROP TABLE IF EXISTS "LiteLLM_SpendLogs_pYYYYMMDD"`, which needs `AccessExclusiveLock` on the parent to update `pg_inherits`. 3. The DDL is blocked waiting for VACUUM. Postgres's lock queue n…