fix(rateLimit): exempt explored entrance DELETE from IP rate limiter

[ClemRz]

🤔 What

• Exempt the DELETE /api/v1/entrances/:entranceId/cavers/:caverId route from the IP-based deleteRateLimit middleware.
• Add a unit test confirming the exemption.

🤷‍♂️ Why

The deleteRateLimit allows regular users only 1 DELETE request per hour per IP. This makes it impractical for a user to manage their exploration list (removing multiple entrances in a session). The endpoint is already protected by tokenAuth and only allows users to remove their own entries, so the destructive-action rate limit adds no meaningful protection here.

🔍 How

Added a path-based skip check in config/rateLimit/rateLimiter.js that matches /api/v1/entrances/<digits>/cavers/<digits> and returns true (skip). The general rate limiter still applies to this route, so it's not unprotected.

🧪 Testing

npm run test -- --grep "Rate Limiter"

All 13 rate limiter tests pass, including the new one.

📸 Previews

N/A

[Paul-AUB]

Suggestions (Should Consider)

1. [test/integration/2_utils/rateLimiter.test.js:295] The test exercises the exemption with unauthenticated requests (req.token is unset). In production, tokenAuth will have already rejected unauthenticated callers before they reach the controller, but the rate-limiter middleware runs before policies apply, so the unauthenticated path is technically valid to test. Still, adding a variant with a req.token set (regular user) would more closely mirror the real call path and document the intended actor.

2. [test/integration/2_utils/rateLimiter.test.js:295] Consider adding a negative assertion: send TEST_USER_DELETE_LIMIT + 5 requests to a path like /api/v1/entrances/42/cavers/7/extra and confirm some return 429. The regex $ anchor already prevents over-broad matching, but an explicit counter-example locks in that invariant and guards against a future regex loosening.

Nitpicks (Optional)

3. [config/rateLimit/rateLimiter.js:139] The inline comment says "tokenAuth already ensures ownership", but tokenAuth establishes authentication, not ownership — the ownership check is in the controller/policy. A more precise phrasing would be "tokenAuth ensures the caller is authenticated, and the controller enforces that users can only remove their own entries". Minor doc inaccuracy, won't affect behaviour.