fix(cors): Expose rate-limit headers in API responses

[IsAvaible]

This PR addresses the issue that #3189 attempted to fix but did not fully resolve. While #3189 added Access-Control-Allow-Origin, it did not set Access-Control-Expose-Headers, which is required to make the rate-limiting headers accessible in browser-based applications.

Issue:

As reported in #2529, API responses do not expose critical rate-limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). This makes it impossible for client-side applications to track rate limits due to CORS restrictions.

Fix:

This PR explicitly sets the Access-Control-Expose-Headers header to expose the required rate-limit headers, allowing web applications to access them properly.

Changes:

Added Access-Control-Expose-Headers with X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset
Ensures CORS policies allow browser clients to read these headers
This should fully resolve the issue and allow web-based API clients to track rate limits correctly.

Let me know if any further adjustments are needed!

[Erb3]

I'm not too familiar with CORS, as you can tell. It hits me now though, wouldn't we also have to set AccessControlAllowMethods?

[IsAvaible]

I'm not too familiar with CORS, as you can tell. It hits me now though, wouldn't we also have to set AccessControlAllowMethods?

GET, HEAD, and POST are always allowed, regardless of whether they are specified in this header, as they are defined as CORS-safelisted methods.
See mdn

I don't think setting AccessControlAllowMethods here is necessary as GET, HEAD, and POST are always allowed and the changed code only sets the CORS response when a rate limit occurs (the standard CORS headers are set in a different part of the codebase).

I think the headers we set here only apply to the ratelimited response. The request that triggered the ratelimit uses the correct standard CORS headers.