### Check for existing issues

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

### What happened?

Applying a budget window (`budget_duration`) to an EXISTING key, user, or team via an update endpoint (/key/update, /user/update, /team/update) sets `budget_reset_at` but does NOT reset the carried lifetime `spend`. An entity that already accumulated spend is therefore instantly over the new cap and gets 429'd on a brand-new budget window.

A key/user/team CREATED with a budget starts at spend=0, so the update path is inconsistent with both the create path and the scheduled ResetBudgetJob (which zeroes spend at window rollover).

Two layers are affected: 1. The DB `spend` field is left unchanged on the update path. 2. The cross-pod spend counter (spend:key:<token> / spend:user:<id> / spend:team:<id>), which get_current_spend reads first, is only invalidated when `spend` is passed explicitly — not when the reset is driven by applying `budget_duration`. So even zeroing the DB spend alone would leave a warm counter at the stale value.

Expected: applying a budget window on update should re-baseline spend (both the DB field and the counter) — but O…