### Check for existing issues

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

### What happened?

When calling `POST /customer/update` on an end-user that has **no existing budget** (`budget_id=null`, e.g. after the budget was deleted via `/budget/delete` which triggers FK ON DELETE SET NULL), and the request includes both `max_budget` and `budget_duration`, a new budget row **is** created in `LiteLLM_BudgetTable`, but `budget_duration` and `budget_reset_at` are silently set to `null`. Only `max_budget` is persisted on the new budget row.

The end-user appears to have a budget (`budget_id` is set, `litellm_budget_table.max_budget` is set), but the reset period is missing — so `reset_budget_job` never resets spend for this budget, and the customer effectively has a one-time non-resetting cap.

## What did you expect to happen?

When `/customer/update` creates a new budget (because `end_user_budget_table is None`), it should persist `budget_duration` **and** compute `budget_reset_at` — exactly like `/budget/new` does ([budget_management_endpoints.py:86-87](https://github.com/BerriAI/litellm/blob/main/litellm/proxy/management_endpoints/budget_…