feat: DI-aware call resolution for TypeScript/NestJS codebases

[joshbouncesecurity]

@

Summary

The TypeScript parser doesn't extract constructor parameter types, so dependency-injected service calls (e.g., this.userService.findById()) end up unresolved in the call graph. This means security analysis silently misses data flow through injected services — a significant blind spot for typical NestJS apps.

This PR adds DI-aware resolution by:

• Extracting constructorDeps metadata from the TypeScript AST.
• Using that metadata to resolve this.service.method() calls to the correct target class.
• Updating the agentic enhancer to consume the new metadata when resolving call edges.

Addresses item 7 from #16 (does not close the issue).

Test plan

• Parse a small NestJS-style sample with a service injected via constructor; verify this.svc.method() resolves to the correct class in the call graph output.
• Sample without DI: parser output unchanged.
• Existing JS/TS tests still pass.
  @

[joshbouncesecurity]

Manual verification

Sample NestJS-style TypeScript:

@Injectable()
class UserService {
  findById(id: string) { return null; }
}

class UserController {
  constructor(private userService: UserService) {}
  get(id: string) { return this.userService.findById(id); }
}

• openant parse <repo-with-above>: call graph for UserController.get includes an edge to UserService.findById (was empty before this PR).
• Multi-dep constructor (constructor(private a: A, private b: B)): edges resolve for both this.a.x() and this.b.y().
• Plain JS file (no type annotations): no crash; parser proceeds, no DI edges (graceful degradation).
• Primitive-typed param (constructor(private name: string)): not treated as a DI target (the type guard skips primitives).
• On a real NestJS app: visual sanity-check that this.<svc>.<method>() calls resolve to the right class in dataset.json.

[joshbouncesecurity]

Local test results

Built a tiny inline NestJS-style fixture with a constructor-injected service and ran the JS analyzer + unit_generator from this branch.

Fixture (.worktrees/_fixtures/nest_di/):

// user.service.ts
export class UserService {
  findById(id: string) { return { id, name: "alice" }; }
}

// user.controller.ts
import { UserService } from "./user.service";
export class UserController {
  constructor(private userService: UserService) {}
  get(id: string) { return this.userService.findById(id); }
}

Commands run:

# Note: had to feed the analyzer a forward-slash file_list to bypass an unrelated
# Windows path bug in this branch (fixed by #46). On Linux/macOS test_pipeline.py
# would have driven this end-to-end with no extra steps.
node typescript_analyzer.js <repo> --files-from posix_list.txt --output analyzer_output.json
node unit_generator.js analyzer_output.json --output dataset.json

Outcome:

• Analyzer extracts new constructorDeps metadata: 'constructorDeps': {'userService': 'UserService'} on UserController.get ✅
• In the resulting dataset.json, UserController.get.metadata.direct_calls includes 'user.service.ts:UserService.findById' — the DI-resolved edge that was missing pre-fix ✅
• UserService.findById.metadata.direct_callers correspondingly includes 'user.controller.ts:UserController.get' ✅
• Did not separately exercise multi-dep / primitive-typed-param / plain-JS / real-NestJS-app paths — covered by the unit tests in the diff.

Side note (unrelated to this PR): there is a self-edge (UserController.get -> UserController.get) in the dataset that looks spurious. May be worth a quick look but doesn't affect this PR's correctness.