fix: resolve route handler for lazily included routers (FastAPI >= 0.137)

[diogocacarneiro-lang]

Fixes the lookup gap reported in #281: with FastAPI >= 0.137, routes added through include_router() are never rate limited by either middleware, and the requests are silently treated as exempt.

Cause

app.routes no longer holds the included routes themselves, only a wrapper. The wrapper has no endpoint, so _find_route_handler returns None for those paths, and _should_exempt(limiter, None) is True. The result fails open and without a log line: the limiter looks installed and configured, but never rejects anything on those routes.

Routes declared directly on the app still limit correctly, which is why this is easy to miss.

Change

_find_route_handler follows the indirection: if a route exposes effective_route_contexts(), its contexts are resolved with the same lookup (each context has both .matches() and .endpoint). getattr(..., None) makes it a no-op on plain Starlette apps and on FastAPI versions that include routers eagerly, so no version guard is needed.

Both SlowAPIMiddleware and SlowAPIASGIMiddleware share this function, so both are fixed by the one change.

Tests

Two tests, in tests/test_fastapi_extension.py:

• test_default_limits_apply_to_routes_from_include_router uses the existing build_fastapi_app fixture, so it runs against both public middlewares (3 parametrisations) and asserts [200, 200, 200, 429, 429] on a 3/minute default limit.
• test_find_route_handler_resolves_lazily_included_routes is a unit test against a stub that exposes effective_route_contexts(), so it documents the contract on any FastAPI version.

Verified red-before / green-after on fastapi 0.140.0, starlette 1.3.1: with the change reverted, all 4 fail; with it, all 4 pass.

Full suite on the same environment: 12 failed, 91 passed before this branch and 12 failed, 95 passed after, i.e. the same failure set plus the 4 new tests. Those 12 pre-existing failures are unrelated to this change (they come from running against a much newer Starlette than the one pinned in pyproject.toml).

Deliberately not included

handler is None meaning "exempt" is what made this failure silent, and it will make the next lookup gap silent too. A warning when a route matched but the handler could not be resolved would turn that into a noisy failure, but it is a behaviour change and belongs in its own PR rather than being smuggled into a fix.

#230 reports _find_route_handler failing for generated routes, which looks like the same lookup being too narrow; this PR does not attempt to cover that case.