feat(cpp-phase2): PR-06 validation-driven bug fixes

[shivasurya]

Summary

Three independent bug fixes uncovered while running PR-01..05 end-to-end against real Ubuntu mingw + a local HTTP server (the validation flow we set up before pushing anything to the production CDN). Each commit is one fix, self-contained.

Stacked on PR-05.

What's in here

1. fix(generator) — IsPrivateSymbol panic on length-1 names

IsPrivateSymbol indexed name[1] after checking len(name) > 0 — a single-underscore symbol ("_", length 1) crashed the generator mid-walk. Surfaced on real Win32 SDK headers; tightened the early-return guard.

Side effect: Linux C registry grew 9,205 → 9,970 functions because the panic was silently aborting some glibc header extractions.

2. fix(generator) — Ubuntu mingw libstdc++ layout

The PR-03 Windows C++ walker probed /usr/x86_64-w64-mingw32/include/c++/<version> (upstream mingw sysroot layout). Debian/Ubuntu's apt install g++-mingw-w64 instead puts libstdc++ at /usr/lib/gcc/x86_64-w64-mingw32/<ver>-<thread>/include/c++/. Every Windows C++ generation on a Ubuntu runner was failing with "no mingw libstdc++ headers" even with the toolchain installed.

findWindowsMingwCppDir now probes both layouts, preferring the posix-threading variant. SystemTag carries a layout suffix so downstream can tell them apart.

Validated against real Ubuntu 24.04 mingw install: windows/cpp/v1 manifest generated successfully — 121 headers, 504 classes, tag mingw-w64-libstdc++-13-posix-ubuntu.

3. fix(registry) — --stdlib-base-url is now the single source of truth

The PR-03 HTTP loader's headerURL preferred the manifest's per-entry URL field over the loader's baseURL. The generator's default --base-url is the production CDN URL, so every manifest baked in production CDN URLs. Result: any --stdlib-base-url override (test, local server, staging deploy) silently bypassed the override and hit the production CDN.

Symptom: pathfinder against a local http://127.0.0.1:8765 server hung indefinitely because the loader fetched the manifest from localhost, then tried to fetch each per-header JSON from https://assets.codepathfinder.dev/... (which doesn't serve them yet).

Fix: headerURL always constructs from baseURL + entry.File. entry.URL stays in the schema for forward compatibility (mirrors, CDN inspection) but the loader doesn't consume it. Two tests pinning the old behavior renamed + repurposed to assert the new contract.

Validation results

HTTP loader vs file:// loader on the same registries, served via Python http.server from $HOME/.test/cpf-clike-registries/:

Project	file://	http://	Δ
smoke fixture	100%	100%	exact
redis	67.3%	67.9%	+0.6 pp
proxygen	28.2%	28.0%	-0.2 pp

≤0.6 pp delta is within run-to-run noise. The HTTP loader is wire-equivalent to file://.

Why this matters

This entire PR exists because we ran the validation flow locally (mingw install + local HTTP server) before pushing anything to R2/CDN. The three bugs would have surfaced in production otherwise:

• Bug Tree-Sitter Implementation with Source Sink Analysis #1 would have crashed the GitHub Actions Windows job
• Bug Parse full method name as identifier #2 would have made the Windows job fail with no diagnostic
• Bug Added support for method query like interface #3 would have silently made every CDN test point at the wrong URL

Local validation paid for itself three times over.

Verification

• gradle buildGo — clean
• go test ./... — all packages pass
• golangci-lint run ./... — 0 issues

Test plan

• CI green
• No regressions on file:// loader behavior

🤖 Generated with Claude Code

[safedep]

SafeDep Report Summary

No dependency changes detected. Nothing to scan.

View complete scan results →

_{This report is generated by SafeDep Github App}

[github-actions]

Code Pathfinder Security Scan

No security issues detected.

Metric	Value
Files Scanned	6
Rules	205

---

_{Powered by Code Pathfinder}

[code-pathfinder]

Pathfinder Report

✅ No security findings on the changed files. This pull request is clean.

View report on the dashboard

---

Powered by Code Pathfinder.

[codecov]

Codecov Report

❌ Patch coverage is 91.66667% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.69%. Comparing base (8f4b90a) to head (9238397).

Files with missing lines	Patch %	Lines
...engine/tools/internal/clikeextract/walker_xplat.go	91.42%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@                             Coverage Diff                              @@
##           shiva/cpp-phase2-pr05-c-transitive-fallback     #718   +/-   ##
============================================================================
  Coverage                                        85.69%   85.69%           
============================================================================
  Files                                              203      203           
  Lines                                            29212    29237   +25     
============================================================================
+ Hits                                             25032    25054   +22     
- Misses                                            3207     3209    +2     
- Partials                                           973      974    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.