fix(extract): resolve Go route paths built via string concatenation

[AmirF194]

What does this PR do?

r.HandleFunc(base+"/login", loginHandler) and outbound calls built the same way ("http://" + host + ":" + port + "/log") were not indexed: extract_positional_url (internal/cbm/extract_calls.c) has no branch for binary_expression, the AST node Go's + produces, so the argument falls through and first_string_arg stays NULL. On the reporter's real BFF (47 HandleFunc registrations, all BaseURL+"literal"), the graph contained only 9 Route nodes.

Added extract_binary_concat_suffix: for a + concatenation, recover the literal string on the right-hand side (the config-prefix pattern this issue describes). When the right side is not itself a literal, the call is left unresolved rather than guessing a path, matching the reporter's own expected behavior.

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

Verification

• New regression test (extract_go_binary_concat_url_issue1249) fails on unmodified main (first_string_arg is NULL) and passes on this branch, covering both the mux registration and the outbound-URL case from the issue.
• A second test confirms a concatenation whose right side is not a literal (base+suffixVar) still resolves to no route, so nothing is fabricated.
• Full extraction suite (273 tests) passes under ASan+UBSan; scripts/lint.sh --ci (cppcheck + clang-format) is clean on the changed files.
• Not run: the full sanitized suite outside extraction, and the macOS/Windows CI legs (no such runners here).

Fixes #1249

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.