Add Retry-After to rate-limited responses

[teta2k]

Summary

• add a numeric Retry-After header to the default 429 rate-limit response
• use the rate limiter's existing time_remaining value for the delay
• document the default header and cover it in responder and Rack middleware tests

Root cause

The rate limiter already attached the remaining window to request.env["aikido.rate_limiting"], but the default responder discarded that information and returned only Content-Type. As a result, clients received a 429 without knowing when to retry.

Custom rate_limited_responder callbacks are unchanged.

Validation

• config, Rack middleware, and Action Controller tests: 50 tests, 312 assertions, 0 failures
• StandardRB on all changed Ruby files
• firewall-tester-action Compose test-rate-limiting-retry-after: passed in 5.05 seconds against the latest Ruby demo app using this branch as a local path dependency

Before this change, the same Compose test reported five rate-limited responses without a Retry-After header.

[aikido-pr-checks]

Summary by Aikido

Security Issues: 0	Quality Issues: 0	Resolved Issues: 0

⚡ Enhancements

• Added numeric Retry-After headers to default rate-limited responses

📚 Documentation

• Documented default Retry-After behavior for rate-limited responses

^{More info}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!