### Check for existing issues

- [x] I searched open and closed issues before filing - [x] I found no existing issue for the check-then-increment race in `max_budget_per_session`

### What happened?

The session budget hook checks accumulated spend before a request, but does not reserve any budget during admission. Actual response cost is added only after each successful request

Two or more requests for the same session can therefore read the same below-budget value and all pass. Their eventual combined cost can exceed `max_budget_per_session` by a multiple of request concurrency

The post-response Redis increment is atomic, but that only makes the final overage accurately visible. It does not make the preceding admission decision atomic and does not prevent the overage

This is especially relevant to parallel agent turns and multi-replica proxy deployments, which are the scenarios where a session-scoped budget needs cross-request coordination

The reproduction uses synthetic agent, key, session, budget, and cost values and makes no provider or network call

### Steps to Reproduce

1. Check out commit `24123269ccb76f36298a2457589f08bd3141072c` 2. Run this script from the repositor…