feat: emit X-RateLimit and Retry-After headers #696

[Fading-Dev]

Overview

This PR adds consistent X-RateLimit-* response headers for rate-limited routes and emits Retry-After only on HTTP 429 responses so clients can back off correctly without mistaking a successful last-token request for a limit hit.

Related Issue

Closes #696

Changes

⏱️ Rate Limit Headers

• [MODIFY] internal/middleware/ratelimit.go

  • Extend RateLimitSnapshot with RateLimited.
  • Emit X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset (unix seconds).
  • Emit Retry-After only when RateLimited is true (429 path).

• [MODIFY] internal/middleware/tenant_ratelimit.go

  • Pass RateLimited: true on tenant limiter rejections so Retry-After is set correctly.

• [MODIFY] internal/middleware/ratelimit_test.go

  • Cover header presence on allowed and rejected requests; assert Retry-After is absent on 2xx.

Verification Results

go test ./internal/middleware/ -count=1
✅ PASS

Acceptance Criteria	Status
X-RateLimit-Limit / Remaining / Reset headers emitted	✅ On limited routes
Retry-After present on 429	✅ When RateLimited
Retry-After absent on successful responses	✅ RateLimited=false on allow path

[drips-wave]

@Godswillopeyemihub Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits