### Summary

A virtual key model update can be undone in the auth cache while the key has active traffic. The database row is updated correctly and the key-management path deletes the cached key, but a successful request that still sees the old cached key can run spend tracking afterward. `update_cache` mutates that `UserAPIKeyAuth` object and queues the full object back into `user_api_key_cache`, so Redis/in-memory auth cache can be repopulated with stale authorization fields such as `models`.

### Reproduction

1. A virtual key has a cached `UserAPIKeyAuth` object with model list `A` 2. `/key/update` changes the key to model list `A + B` and invalidates the auth cache 3. Concurrent successful traffic for the same key completes after the update 4. Spend tracking reads the cached key object, updates spend fields, and writes the full key object back through `user_api_key_cache.async_set_cache_pipeline` 5. The auth cache contains stale model list `A` again, so requests to model `B` fail with `key_model_access_denied` until the stale writer stops or cache entries expire

### Expected behavior

Spend tracking should not write the full auth object back into the virtual-key auth cache. A…