fix(api-server): apply rate limiting before auth to prevent API key brute-force

[joshfatoye0011-bit]

Problem The

oute_layer order in main.rs placed �uth_middleware as the outermost layer, so it ran before
ate_limit_middleware. Requests with an invalid or missing API key were rejected by auth (401/403) before the rate limiter ever saw them — meaning an attacker could brute-force ROUTER_API_KEY with unlimited attempts per second, completely bypassing the rate limiter. ## Fix Swap the two .route_layer calls so
ate_limit_middleware is added last (outermost) and therefore executes first on every incoming request, regardless of the API key supplied. \
ust // Before (broken) .route_layer(from_fn_with_state(rate_limiter, rate_limit_middleware)) // inner — skipped on bad key .route_layer(from_fn_with_state(auth_config, auth::auth_middleware)); // outer — ran first // After (fixed) .route_layer(from_fn_with_state(auth_config, auth::auth_middleware)) // inner .route_layer(from_fn_with_state(rate_limiter, rate_limit_middleware)); // outer — runs first \\ The
eplay_protection_middleware on /simulate is unaffected — it is correctly innermost. ## Tests added - ** est_rate_limit_applies_to_invalid_api_key_requests** — sends repeated requests with a wrong key and asserts the response becomes 429 (with Retry-After header and error: rate_limit_exceeded body) once the quota is exhausted. - ** est_valid_key_still_works_after_invalid_key_is_rate_limited** — asserts that exhausting one key's rate-limit bucket does not affect a separate key's bucket. ## Acceptance criteria - [x] Rate limiting applies to requests before auth outcome - [x] Repeated invalid API keys eventually receive 429