Extend kind detection to remaining frameworks (pages + websockets)

[jorgeraad]

After #2 (kind field) and #3 (Next.js page extraction), other framework extractors still emit kind: "api" for everything — even routes that are clearly pages or websockets in their respective frameworks. Tracking the remaining gaps as a checklist; each row can land as a separate PR.

Pages

• Spring — @Controller (page) vs @RestController (api). Class-level annotation, easy.
• NestJS — @Render('view') decorator on controller methods.
• Laravel — routes/web.php is page-shaped; handler returning view().
• Flask — handler body containing render_template(...).
• FastAPI — routes returning HTMLResponse or Jinja2Templates.TemplateResponse.
• Express — handler body containing res.render(...) or res.sendFile(...).
• Django — CBV TemplateView/ListView/DetailView with template_name; FBV returning render(...).
• Rails — controllers inheriting ActionController::Base (page) vs ActionController::API (api).

WebSockets

• NestJS — @WebSocketGateway() + @SubscribeMessage() decorators.
• Django Channels — websocket_urlpatterns in routing.py, AsyncWebsocketConsumer subclasses.
• Spring — @MessageMapping, @SubscribeMapping, WebSocketHandler implementations.
• Express — socket.io, ws, express-ws (io.on('connection', ...) patterns).
• Go — gorilla/websocket, gin c.Upgrade().

Already done: Next.js (#3), FastAPI (@router.websocket() already emits kind: "websocket").

Per-PR requirements

Each row above lands as its own PR (single extractor file + fixture). For every PR:

• Verify the emitted kind is correct for the new category. Add fixture test cases under src/extractors/__fixtures__/<framework>/ that assert kind: "page" (or "websocket") on the new detection paths AND that existing API-route detection in the same extractor still emits kind: "api" (no regressions). The test must fail if the wrong kind is returned for either category.
• No regressions on previously emitted endpoints — a multi-route fixture exercising both old and new detection paths in one scan.
• Document the detection signal in the extractor's source as a brief comment near the new code path (file convention used / decorator name / class hierarchy / etc.) so future contributors can extend it.

Per-framework PRs are small (single extractor file + fixture test). Easiest wins are class-annotation-driven detection (Spring, NestJS); body-inspection (Flask, Express, Laravel view()) is middle-difficulty; class-hierarchy detection (Django CBV, Rails) is most involved.

Builds on #2. Test infrastructure landing in #4 makes the verification step mechanical.