### What happened?

For Azure deployments the router refuses to identify the underlying model unless `model_info.base_model` is set explicitly — **even when the deployment's model name exactly matches a static-map key**. E.g. `litellm_params.model = "azure/gpt-5.4"` with `azure/gpt-5.4` present in `model_prices_and_context_window.json` still logs, on every request:

``` Could not identify azure model 'gpt-5.4'. Set azure 'base_model' for accurate max tokens, cost tracking, etc. ```

On a busy proxy this is thousands of ERROR lines/day per multi-deployment group, and the context-window pre-call check can't see token limits until an operator hand-sets `base_model` on every DB row.

The rationale for requiring `base_model` (Azure deployment names are arbitrary) doesn't apply when the name is an exact map key for the azure provider — the lookup that `base_model` would trigger is exactly the one the router could already do.

### Proposed fix

In `Router._get_model_from_alias`/`get_router_model_info` azure branch (currently `router.py` ~8497 on `litellm_oss_daily_2026_07_13`): when `base_model` is unset and `custom_llm_provider == "azure"`, check whether `azure/<model>` (or `<model>`) is…