feat(entrypoints): Stage 3 detectors — JS/TS, Java, C#, PHP, Cairo, more

Extends framework-aware entrypoint detection to the remaining high-value
languages. Added detectors:

- JavaScript/TypeScript: NestJS controller decorators (@Get/@Post/etc.),
  Next.js App Router (route.ts named HTTP-verb exports), Next.js Pages
  API (pages/api/** handlers), AWS Lambda (exports.handler / export
  handler).
- Java: Spring MVC/WebFlux (@GetMapping, @PostMapping, @RequestMapping,
  etc.), JAX-RS (@GET/@POST/...), @KafkaListener, servlet doGet/doPost
  methods.
- C#: ASP.NET Core [HttpGet]/[HttpPost]/[Route], Azure Functions
  [Function]/[FunctionName].
- PHP: Symfony #[Route(...)] attributes and old-style @route annotations.
- Cairo/StarkNet: #[external], #[view], #[l1_handler], #[constructor].
- Circom: files declaring `component main`.
- Miden Assembly: `export.<name>` directives.
- Haskell: top-level main :: IO () / main = ... bindings.
- Erlang: functions listed in -export([...]).

Refactored the internal decorators_above helper to scan a window around
the node's start_line rather than strictly backwards — different parsers
disagree about whether decorators fall inside or outside the function's
reported span. Python puts start_line on the `def` (decorators above);
Java/C# put it on the first annotation (decorators at or below).
Scanning a ±window handles both without per-parser branching.

Remaining languages (Go beyond main(), Rust beyond the proc-macro
handlers already covered, C/C++, Ruby) await either parser-level
visibility/class-hierarchy info or explicit call-graph tracing for
router-registration patterns (Express, http.HandleFunc, etc.).

7 new tests covering NestJS, Next.js App Router, Spring, JAX-RS, ASP.NET
Core, Symfony, and Erlang -export.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: tob-scott-a