### Check for existing issues

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

### The Feature

Add an optional **gateway-side queue protocol** for overloaded/self-hosted backends, so LiteLLM Proxy can expose structured queue metadata instead of only returning a raw `429`.

Today, when a self-hosted backend such as vLLM, Ollama, or an internal inference gateway is saturated, the practical outcomes are usually:

- the upstream returns `429 Too Many Requests` - the client retries blindly using `retry-after` - or the request is simply rejected and the client has no visibility into whether work is waiting, how long it may take, or whether the server is just overloaded

I am proposing a provider-agnostic, opt-in mechanism for the **Proxy** layer to expose structured waiting state, for example:

```json { "queue_position": 5, "estimated_wait_seconds": 18, "message": "Server busy, waiting for resources" } ```

This does not have to be tied to one exact transport. Possible designs:

1. SSE event during streaming requests, for example:

```text event: queue_status data: {"queue_position": 5, "estimated_wait_seconds": 18, "message": "Server busy…