feat(quota): add server‑side per‑client request quotas (requires auth)

[liangwen12year]

What does this PR do?

feat(quota): add server‑side per‑client request quotas (requires auth)

Unrestricted usage can lead to runaway costs and fragmented client-side
workarounds. This commit introduces a native quota mechanism to the
server, giving operators a unified, centrally managed throttle for
per-client requests—without needing extra proxies or custom client
logic.  This helps contain cloud-compute expenses, enables fine-grained
usage control, and simplifies deployment and monitoring of Llama Stack
services.  Quotas are fully opt-in and have no effect unless explicitly
configured.

Notice that Quotas are fully opt-in and require authentication to be
enabled. The 'sqlite' is the only supported quota `type` at this time,
any other `type` will  be rejected. And the only supported `period` is
'day'.

Highlights:

- Adds `QuotaMiddleware` to enforce per-client request quotas:
  - Uses `Authorization: Bearer <client_id>` (from
    AuthenticationMiddleware)
  - Tracks usage via a SQLite-based KV store
  - Returns 429 when the quota is exceeded

- Extends `ServerConfig` with a `quota` section (type + config)

- Enforces strict coupling: quotas require authentication or the server
  will fail to start

Behavior changes:
- Quotas are disabled by default unless explicitly configured
- SQLite defaults to `./quotas.db` if no DB path is set
- The server requires authentication when quotas are enabled

To enable per-client request quotas in `run.yaml`, add:
```
server:
  port: 8321
  auth:
    provider_type: "custom"
    config:
      endpoint: "https://auth.example.com/validate"
  quota:
    type: sqlite
    config:
      db_path: ./quotas.db
      limit:
        max_requests: 1000
        period: day

Closes #2093

Test Plan

[Describe the tests you ran to verify your changes with result summaries. Provide clear instructions so the plan can be easily re-executed.]

[leseb]

@liangwen12year please resolve conflicts

[leseb]

I expected this to work alongside the authentication middleware, but that doesn’t seem to be the case currently. As it stands, rate-limiting accepts any Bearer token without validation, so someone could bypass it by simply altering the token. Could we enforce the presence of a valid auth configuration as a prerequisite for enabling rate-limiting?

Am I missing something?

[liangwen12year]

I expected this to work alongside the authentication middleware, but that doesn’t seem to be the case currently. As it stands, rate-limiting accepts any Bearer token without validation, so someone could bypass it by simply altering the token. Could we enforce the presence of a valid auth configuration as a prerequisite for enabling rate-limiting?

Am I missing something?

Thanks for the hint, we definitely need to have the authentication first.

[leseb]

can you remove the uv.lock from this PR?

[leseb]

I think there is a case to be made for authenticated users having a higher amount of requests than anonymous. Now I'm starting to wonder if we shouldn't support quota with auth disabled and give a low quota. What do you think?

Sorry for the back and forth on auth required versus not required 😅

[liangwen12year]

can you remove the uv.lock from this PR?

Removed, thanks !

[liangwen12year]

I think there is a case to be made for authenticated users having a higher amount of requests than anonymous. Now I'm starting to wonder if we shouldn't support quota with auth disabled and give a low quota. What do you think?

I completely agree, there’s a strong case for supporting quotas even when authentication is disabled. This would allow the system to gracefully throttle anonymous users rather than blocking them entirely, encourage users to sign up by offering a higher quota for authenticated accounts, and provide a safeguard against abuse even in the absence of authentication. It would also make the middleware more flexible and applicable to a wider range of real-world API use cases.

A practical approach could be to use the authenticated_client_id as the key when authentication is enabled, and fall back to an alternative like the client’s IP address (from scope["client"]) when it’s not. It might be valuable to introduce two configurable limits: one for anonymous users (with a low default) and a higher one for authenticated users.

Overall, I think this is a meaningful improvement that would make the feature much more versatile.

[leseb]

One nit and we should be good to go, thanks for your patience!