fix: resolve URL-builder helper calls to Route/HTTP_CALLS

[CharlesQueiroz]

Fixes #1009. Stacked on #1008 (includes its commit; rebases cleanly once #1008 lands).

Root cause

URL-shaped literals returned from small builder functions never reach a call argument, so client(buildPath(id)) had no first_string_arg: no HTTP_CALLS edge, no Route node, static and template literals alike. lookup_string_constant only covers module-level consts.

Fix

• handle_url_builders() (extract_unified.c, runs in the unified walk): when a return statement (or an arrow-function expression body) yields a URL-shaped literal, records builderName -> url in the same per-file constant map used for module-level consts. Ambiguous builders (two different URLs for one name) are tombstoned so lookups miss instead of guessing.
• extract_url_or_topic_arg() (extract_calls.c): a call_expression argument whose callee is a plain identifier resolves through that map, giving the call its first_string_arg; the existing pipeline then mints the Route node and the HTTP_CALLS edge from the real HTTP caller (the hook), not from the builder.
• Composed builders: the builder-body template flatten is map-aware: a ${...} substitution that is a bare identifier or a call to an already-recorded name inlines that value, everything else becomes {}, and the result is truncated at the first ? (query strings are not part of a route's identity). This covers the real-world TanStack shape:

function activityPath(id: string) { return `/api/v1/team-members/${id}/activity` }
function buildPath(id: string, cursor: string) {
  const params = new URLSearchParams()
  return `${activityPath(id)}?${params.toString()}`
}
apiFetch(buildPath(id, cursor))   // -> HTTP_CALLS -> /api/v1/team-members/{}/activity

Same-file scope, document order (same constraints the const map already has).

Validation

• New regression tests extract_ts_url_builder_issue1009 (return + arrow bodies) and extract_ts_url_builder_composed_issue1009 (composition + query truncation).
• Full suite: 5988 passed, 1 skipped, 0 failures.
• End-to-end fixture: queryFn -HTTP_CALLS-> /api/v1/team-members/{}/activity now exists for the builder shape, joining the server-side __route__GET__/api/v1/team-members/{}/activity exactly.

[CharlesQueiroz]

Pushed a follow-up commit: detect_url_in_args() (the arg_url HTTP_CALLS emitter used when the callee is a local client wrapper rather than a known HTTP library) reads per-arg values, not first_string_arg. The builder-map resolution and template flattening are now applied there too, so wrapper clients like apiFetch(buildPath(id), opts) emit the edge. Validated end-to-end on a real TanStack codebase: the parameterized hooks now produce HTTP_CALLS -> /api/v1/team-members/{}/activity, joining the server route exactly. Suite still 5988 passed / 0 failed.

[DeusData]

Thanks for sending this follow-up. I have triaged it into 0.9.1-rc as the fix candidate for #1009. Review focus will be the stacked dependency on #1008, builder ambiguity handling, and avoiding speculative cross-repo routes that could create false positives.

[CharlesQueiroz]

Rebased onto the updated #1008 with sign-offs on both commits; no content changes. Full suite passes locally on the stacked branch.

[CharlesQueiroz]

Rebased the stack onto the updated #1008, which now sits on current main. The only conflict was the adjacent handler registration from another merged PR in extract_unified.c, resolved keeping both. Full suite on the stacked branch: 6360 passed, 1 skipped, 0 failures. lint-format clean. Once #1008 lands this rebases onto main trivially.