feat(BA-7363): publish the per-user rate limit to the shared Redis DB

[jopemachine]

📚 Stacked PRs

This PR is part of a 5-PR stack. Merge in order:

1. ⬇️ feat(BA-7364): deliver the login user id in the auth response #13777 — feat(BA-7364): deliver the login user id in the auth response
2. ⬇️ feat(BA-7365): key the rate limit counter by user id #13778 — feat(BA-7365): key the rate limit counter by user id
3. ⬇️ feat(BA-7362): move the per-user API rate limit to the user resource policy #13779 — feat(BA-7362): move the per-user API rate limit to the user resource policy
4. 👉 feat(BA-7363): publish the per-user rate limit to the shared Redis DB #13784 — feat(BA-7363): publish the per-user rate limit to the shared Redis DB ← you are here
5. ⬇️ feat(BA-7365): add a per-user rate limit middleware to the web server #13771 — feat(BA-7365): add a per-user rate limit middleware to the web server

Only the final tip (#13771) is guaranteed to build / pass CI; intermediate PRs are logical slices for reviewability.

Summary

• Add set_user_rate_limit() / get_user_rate_limit() to ValkeyRateLimitClient, storing the value under a user-rate-limit.<user_id> key in the rate limit DB that already holds the rolling counters.
• The manager's rate limit middleware republishes the user's policy value on every authorized request. It resolves that value per request anyway, so the published copy never goes stale: a lowered limit reaches the web server on the user's next proxied request.
• The TTL is the rate limit window, so a limit that stops being republished expires at the same time its rolling counter would.

The web server reads this value instead of carrying the limit in its session token, which would have frozen it at login time for up to a week.

Resolves BA-7363.