HTTP_CALLS conflates client-side router navigation (Angular router.navigateByUrl) with real HTTP calls

[mmaripanguec]

What is broken

In Angular/Ionic frontends, HTTP_CALLS edges are created for client-side navigation, not just network calls. The callee property makes the origin obvious:

{"via": "arg_url", "callee": "this.router.navigateByUrl", "url_path": "/home/payments"}
{"via": "arg_url", "callee": "component.onGoTo",          "url_path": "/home/benefits"}

Minimal repro (TypeScript)

this.router.navigateByUrl('/home/payments');   // UI navigation -> becomes HTTP_CALLS
this.http.post(environment.API + '/login', b); // actual HTTP call

Observed impact

In a real PWA, the large majority of its 253 HTTP_CALLS edges were router navigations. Any consumer that uses HTTP_CALLS to derive service-to-service communication (cross-repo maps, dependency graphs) has to hand-maintain a denylist of router callee patterns to avoid inventing traffic between repos.

Expected

Either (a) don't emit HTTP_CALLS for known client-side navigation APIs (Router.navigate*, Location.go, history APIs), or (b) emit them as a distinct edge type (e.g. NAVIGATES_TO), keeping HTTP_CALLS for actual network client calls (HttpClient/fetch/axios). The callee heuristic exists already — it just needs to gate the edge type.

[DeusData]

Confirmed against current main. Once a call is classified as HTTP, the current path gate accepts any first string argument beginning with / and emits HTTP_CALLS; it does not reject client-side navigation callees. The 0.9.1-rc correctness fix should suppress false HTTP_CALLS for known router/history APIs while preserving real HttpClient, fetch, and axios calls. A new NAVIGATES_TO edge would be separate feature/API work, not required for this bug fix. Tracked under #592.