JS/TS: URL-builder helper pattern (URL returned from a function) produces no Route/HTTP_CALLS

[CharlesQueiroz]

Follow-up to #1006 (and orthogonal to the fix in PR #1008).

Observed

URL-shaped string literals that live inside a function body in return position are collected as string refs but never become Route nodes or HTTP_CALLS edges, regardless of literal kind (static string or template literal):

const LIST_PATH = '/api/v1/things'          // module-level const -> Route: OK

export function detailPath(id: string) {
  return `/api/v1/things/${id}/detail`      // no Route, no HTTP_CALLS
}

export function staticPath() {
  return '/api/v1/statics/detail'           // no Route either -> not a template-literal problem
}

This is the common "URL-builder helper" pattern in React Query / TanStack codebases: a small function builds the parameterized path, and the hook passes the result (an identifier) to the HTTP client, so first_string_arg resolution cannot see it either (lookup_string_constant only covers module-level consts).

Impact

Every parameterized endpoint consumed through a builder helper is invisible to cross-repo route intelligence even after #1006: in our FE+BE pair, all /{id}/... endpoints follow this pattern.

Suggestion

Route-ify URL-shaped string refs whose enclosing function is a plain URL builder (single return of the literal), attributing the HTTP_CALLS edge to the callers of that builder; or at minimum expose these refs as Route nodes so the deterministic route-name join works, even without the edge.

Verified on a v0.9.0-based build that already includes the #1008 template-literal flattening, so this is not a duplicate of #1006.

[DeusData]

Thanks for the precise follow-up. I have triaged this as a 0.9.1-rc parsing/quality bug. PR #1010 is the current fix candidate; review will focus on builder ambiguity handling and avoiding speculative cross-repo routes.