LiteLLM custom_auth_run_common_checks does not enforce key-level max_budget on custom-auth requests

Finding: In one external report against LiteLLM v1.104.2 (Docker, Postgres, general_settings.custom_auth with custom_auth_run_common_checks: true), the key-level max_budget reportedly is not enforced for requests authenticated by a custom authenticator that returns a virtual key's UserAPIKeyAuth. Source: https://github.com/BerriAI/litellm/issues/45605 Reported symptom: the reporter created a key with max_budget 1.0 and budget_duration 2m, then made five chat completions through custom auth against a mock model priced at 1 USD per token. Every call returned 200, /key/info showed spend far above max_budget, and budget_reset_at was set. Expected was a 422 ExceededBudget from the second call on. No exact error string was captured because nothing was blocked (https://github.com/BerriAI/litellm/issues/45605). Reported controls: with a user row (user_id with max_budget) attached to the same key, the next call returned 422 from the user budget check, which indicates common_checks was running. With custom_auth removed and the key used directly as bearer, key max_budget was enforced with 422 (https://github.com/BerriAI/litellm/issues/45605). Hypothesis (reporter's code reading, not maintainer-confirmed): the common_checks budget gather covers user, team and multi-budget (budget_limits) checks but omits virtual_key_max_budget_check, which is called only from the stock virtual-key branch of _user_api_key_auth_builder. The reporter cites main at commit 6d4fa56 and says the path is unchanged there, and notes the docs describe the option as running standard budget checks (https://github.com/BerriAI/litellm/issues/45605). The reporter proposes adding virtual_key_max_budget_check to the gather, guarded on max_budget not being None. Status: a contributor commented they would take the issue and later said a fix is up as #45619 (https://github.com/BerriAI/litellm/issues/45605#issuecomment-6085925160). That PR is not among the supplied sources, so its content, review and merge state are unknown, and no released fix version is known. No maintainer has responded in the supplied comments. Practical implication: if you rely on custom_auth with key-level max_budget, the reported behavior suggests that limit may not be enforced; user- or team-level budgets reportedly are. Check spend via /key/info against max_budget. The reporter's controls are diagnostic observations, not a verified remedy. Limitation: this is an external report; KFA did not reproduce it. Cause, fix and affected versions beyond v1.104.2 remain unverified.