Framework-aware reachability for Angular (and similar JS/TS frameworks)

dep-scan + atom currently treat Angular projects as generic JS/TS. In practice this produces a high false-negative rate for reachability: a large portion of application code looks unreachable because the real entry points and call chains live in framework constructs that the generic JS frontend can't follow.

The following are invisible in an Angular codebase today:

- Class members referenced only from HTML templates (`{{ }}`, `[prop]`, `(event)`, `*ngIf`/`*ngFor`, and the `@if`/`@for` syntax in v17+)
- Constructor-injected services and the `inject()` function
- Lazy-loaded routes via `loadChildren: () => import(...)`
- Lifecycle hooks (`ngOnInit`, `ngOnDestroy`, etc.) called by the framework rather than user code
- Decorator-driven entry points (`@Component`, `@Injectable`, `@HostListener`, `@ViewChild`)

The result is that "non-reachable" classifications can't be trusted for Angular apps, which defeats the main reason to enable reachability.

Two questions before considering any contribution:

1. Is framework-aware analysis in scope for atom, or is the design intentionally framework-agnostic and this kind of work expected to live elsewhere?
2. If it is in scope, is there a preferred direction between a heuristic frontend (decorator-based entry points, template-string matching, route-string following; cheaper, roughly 80% of value, imprecise) and a semantic frontend (reuse `@angular/compiler` to parse templates properly into the CPG; much more work, accurate, version-coupled to Angular)?

Want to understand direction before prototyping.