feat(middleware): optional RateLimiterStoreContext for response headers (#2961)

[vishr]

Problem (#2961)

The rate limiter sets no Retry-After / X-RateLimit-* headers, and the RateLimiterStore interface (Allow(identifier) (bool, error)) gives a store no way to set them either.

Fix

Add an optional interface:

type RateLimiterStoreContext interface {
	AllowContext(c *echo.Context, identifier string) (bool, error)
}

When the configured store implements it, the middleware calls AllowContext (with the request context) instead of Allow, so the store can set response headers on the allow/deny decision.

Fully backward compatible — stores implementing only Allow are unaffected; the existing interface and the built-in memory store are unchanged.

This is the optional-interface approach @aldas proposed in the issue thread (mirroring the pattern used in the v4 proxy middleware). It intentionally does not retrofit the built-in store with full metadata plumbing (the part flagged as a larger rewrite in the thread) — it just provides the hook so stores can set headers.

Test

TestRateLimiter_storeAllowContextIsPreferred (written first; fails before the change): a store implementing AllowContext is preferred over Allow and can set a Retry-After header. gofmt/vet clean; full rate-limiter suite passes (backward compat confirmed).

Addresses #2961.

🤖 Generated with Claude Code

[aldas]

Note: this is same (subset) change as #2985 does but @leno23 created that PR against v4.