Go: mux registrations built by runtime concatenation (prefixVar + "literal") are not resolved — most of a service's routes missing

[mmaripanguec]

What is broken

Route registrations whose path is a compile-time-obvious concatenation of a config variable and a string literal are not indexed, so the graph misses most of the service's surface.

Minimal repro (Go, gorilla/mux)

r := mux.NewRouter()
r.HandleFunc(settings.V.BaseURL+"/login", loginHandler)          // MISSED
r.HandleFunc(settings.V.BaseURL+"/v2/login", loginV2Handler)     // MISSED
r.HandleFunc(settings.V.BaseURL+"/widget/{rest:.*}", widget)     // MISSED
r.HandleFunc("/health", health)                                   // indexed OK

Observed impact

In a real BFF with 47 HandleFunc registrations (42 unique paths), all of them using the BaseURL+"literal" pattern, the graph contained only 9 Route nodes — and several of those came from logger labels rather than registrations (see #1248). The same limitation hides outbound calls built the same way (url := "http://" + host + ":" + port + "/log" produced no HTTP_CALLS edge), so a real cross-service seam was invisible.

Expected

When the non-literal part is a simple identifier/selector (config prefix) and the rest is a literal, index the literal suffix as the route path (optionally recording the dynamic prefix in a property, e.g. {"prefix_var": "settings.V.BaseURL"}). This pattern is idiomatic in Go services that mount everything under a configurable base path.

[DeusData]

Thanks. This is a real extraction gap rather than a request to fabricate a complete runtime path. The RED should preserve the literal suffix from prefixVar + "/route", associate it with the actual mux registration call, and avoid claiming a fully static route when the prefix cannot be resolved. High priority for 0.9.1-rc under #592.