### Check for existing issues

- [x] I searched open and closed issues before filing - [x] Existing end-user budget reports such as [#34238](https://github.com/BerriAI/litellm/issues/34238) concern spend counters, not the `blocked` field

### What happened?

`POST /customer/block` documents that subsequent LLM requests carrying the blocked end-user ID will be rejected, but the core auth path never checks `LiteLLM_EndUserTable.blocked`

The endpoint writes `blocked=True` to Postgres even when the optional enterprise blocked-user callback is not configured. `get_end_user_object` loads that row for budget checks, but `common_checks` only checks the end-user budget and does not reject a blocked object. In an OSS or enterprise deployment without that callback, the block API succeeds while later requests continue

The optional enterprise callback does check the database field, but it caches the result under `litellm:end_user_id:{id}` for 60 seconds. `/customer/block` does not invalidate that cache or the core auth cache `end_user_id:{id}`, so a warmed unblocked entry remains usable until expiry

The inverse endpoint has a separate consistency problem. `POST /customer/unblock` requires th…