fix(parsers/javascript): extract Express anonymous route handler callbacks (#21)

[ChrisJr404]

Closes #21.

The analyzer never walked into call-expression argument lists, so when a route was defined idiomatically as

```js
router.post('/orders', authenticateToken, async (req, res) => { ... });
```

the only thing it picked up was the named middleware reference. The actual handler body — where most of the application's business logic and vulnerabilities live — was invisible to every downstream stage, which is why `reachability_filter` was dropping ~75% of the units in the example codebase.

Approach

New `_extractRouteHandlerCallbacks` pass on every source file that walks every `CallExpression`, detects the Express verb shape (`.{get,post,put,patch,delete,options,head,all,use}(...)`), and extracts each `ArrowFunction` / `FunctionExpression` argument as its own unit with:

• synthetic name ` ` (e.g. `POST /orders`) when the path is a string literal — matches the "method and path as metadata" bullet under "Expected behavior" in the issue.
• `unitType: "route_handler"` so the existing classifier downstream doesn't have to re-derive it from the body.
• `isEntryPoint: true` so `reachability_filter` treats it as a request-data entry the way it already treats named `(req, res)` middleware.
• `httpMethod` / `httpPath` carried through for any follow-up step that wants to render route info.

Multi-callback registrations (chained middleware + final handler) get suffixed with their post-path arg index — `POST /orders` for the first callback, `POST /orders [1]` for the second, etc — so they don't collide.

`SyntaxKind.CallExpression` is resolved off the typescript dep at call time (its numeric value drifts between releases — 213 in older versions, 214 in 5.x) rather than hard-coded.

Smoke test

Ran the analyzer against the issue's example file plus three additional shapes:

```
$ node -e "const { TypeScriptAnalyzer } = require('./typescript_analyzer.js');
const a = new TypeScriptAnalyzer('/tmp/express_test_repo');
const result = a.analyzeFiles(['routes.js']);
for (const [id, f] of Object.entries(result.functions)) {
console.log(id, '| type=' + f.unitType, '| entry=' + (f.isEntryPoint||false),
'| method=' + (f.httpMethod||''), '| path=' + (f.httpPath||''));
}
"
routes.js:POST /orders [1] | type=route_handler | entry=true | method=POST | path=/orders
routes.js:GET /users/:id | type=route_handler | entry=true | method=GET | path=/users/:id
routes.js:USE /api | type=route_handler | entry=true | method=USE | path=/api
routes.js:DELETE /items/:id [2] | type=route_handler | entry=true | method=DELETE | path=/items/:id
```

Named middleware references (`authenticateToken`, `authorizeAdmin`) correctly stay out of the unit list since they parse as `Identifier`, not `ArrowFunction` / `FunctionExpression`. The existing variable-decl and module.exports passes still pick those up where they're defined.

What's not in scope

• Hapi / Koa / Fastify use a different shape — `server.route({ method, path, handler: () => {...} })` — and would need separate detection. Left out so this PR is focused on the Express case the issue described.
• Method names spelled different from `router` / `app` — the detector looks at the verb suffix only, not the receiver. So `myCustomRouter.post('/x', handler)` works the same way `app.post` does. If you'd prefer a tighter receiver allowlist, easy to swap in.
• Route handlers passed indirectly (`const h = (req, res) => {...}; router.post('/x', h)`) — the variable-declaration pass already extracts `h`, so reachability_filter sees it via that name. Worth flagging for review in case you'd rather de-dup or tag it as a route handler too.

Test plan

• Manual smoke test against the issue's example file (4 routes → 4 units, all flagged `isEntryPoint`)
• Verified named-middleware references stay out of the unit list (no double-extraction)
• No JS-side test harness exists in the repo for the parser, so I'm relying on the smoke test above plus your CI for downstream regressions. Happy to bolt on a small node-based test suite for the analyzer in a follow-up if you want one.

[ar7casper]

Hey @ChrisJr404 — thanks for jumping on Issue #21 and for the detailed approach + smoke test. Your diagnosis was spot on: the analyzer never walked into Express callback argument lists, and reachability_filter was dropping ~75% of units on the example codebase as a result.

We ended up going with PR #49 (@joshbouncesecurity) for this one and have already merged it as part of release/2026-05-12. The two PRs identified the same root cause; #49's implementation just covered a few more edges that mattered for the broader pipeline:

• Receiver filter — only app / router / routes / server (+ chained .route(...) / .Router()) match. Prevents false positives on myCache.get(...), queryBuilder.post(...), etc.
• Named middleware → call-graph edges — app.post('/x', authenticateToken, handler) now emits an edge from the synthetic handler to authenticateToken, so the LLM stage can see the auth chain.
• Handler vs middleware distinction — last callback is route_handler (entry point), earlier ones are route_middleware.
• Route metadata in dataset.json — http_method, http_path, callback_index, named_middleware.
• callGraph invariant maintained (with regression test) — the synthetic units are now keys in callGraph, not just functions.
• 10 tests including a negative case for non-Express receivers, plus full CI green.

None of that means your PR was wrong — it just landed at a different point on the precision/coverage tradeoff. Closing this one as superseded by #49.

A few of your other PRs are next on our review queue (#52 OpenRouter, #53 --staged diff, #34 SARIF). Looking forward to going through those — really appreciate you contributing to the project.