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.

[Mukller]

Triage note for the cluster of PRs fixing included-router rate limiting (#285, #286, #282): I verified all three functionally on FastAPI 0.141.1 with a uniform probe (default_limits only, SlowAPIMiddleware, decorator-free endpoint — the path where only _find_route_handler can enforce):

app.include_router(sub)            -> second request status
app.include_router(sub, prefix="/sub")

master : 200,200 BYPASSED   | 200,200 BYPASSED     (bug confirmed)
#285   : 200,429 ENFORCED   | 200,429 ENFORCED
#286   : 200,429 ENFORCED   | 200,429 ENFORCED
#282   : 200,429 ENFORCED   | 200,200 BYPASSED    <- prefixed case still leaks

Findings specific to this PR:

• The recursion via effective_route_contexts() works against real 0.141 internals (_IncludedRouter exposes it), and your unit test's mocked shape matches reality.
• One semantic difference vs the other two candidates worth knowing about: you keep the original last-match-wins scan (handler = inner; continue), while #286 returns on the first FULL match. On apps where several routes could match the same scope, behavior may differ from pre-0.137 slowapi — might be worth an explicit decision/test.
• Your suite passes locally for me (61 passed, incl. the new default-limits integration test).

Version coverage question for maintainers: #285 keys off effective_route_contexts (≥0.137 lazy inclusion), #286 keys off _effective_candidates (the _IncludedRouter attr present in ≥0.140 builds I inspected), and #282 tries .routes/original_router.routes. All three attributes coexist on 0.141.1 — so the practical choice is about which older FastAPI lines you want to keep supporting, since the attribute landscape changed between 0.137–0.140.