fix(go): resolve cross-package field-chain calls via type dispatch

[xkchok]

Summary

Go calls written through an aliased cross-package struct field (h.svc.Method(ctx, req)) previously fell through to fuzzy suffix matching instead of type dispatch. Three defects caused it:

1. Dispatch walk bypassed — the per-file Go dispatch walk in cbm_pxc_dispatch_file was bypassed, so field selectors were never descended.
2. Struct fields dropped — fields extracted as flat Field defs were discarded by the LSP label map, so every Go struct registered with zero fields in the cross-file registry.
3. Import-alias receiver QNs unresolvable — type texts written through aliases produced qualified names that exist nowhere in the registry.

Changes

• internal/cbm/lsp/go_lsp.c — restore the Go field-chain walk: descend receiver.field selectors through the shared prebuilt registry and emit lsp_type_dispatch / lsp_embed_dispatch edges; add go_requalify_via_imports to re-qualify alias segments through the calling file's import map when the direct receiver-type lookup misses.
• internal/cbm/extract_defs.c + src/pipeline/pass_lsp_cross.c — fold per-field Field defs into their owning struct inside cbm_pxc_collect_all_defs (one site covers both the prebuilt-registry path and the per-file fallback).
• tests/test_parallel.c — regression: a cross-package field chain resolves end to end with an lsp_type_dispatch edge from the parallel resolver.
• tests/test_go_lsp.c — regression: an alias-typed struct field re-qualifies through the import map and lands on the real receiver type.

Separate chore commit (drop it if unwanted): env-gated dispatch tracing (CBM_DISPATCH_TRACE / CBM_TRACE_FILE, file sink) in go_lsp.c, since resolve-worker stderr is swallowed by the daemon supervisor. No behavior change when unset.

Test plan

• make test-runner clean build
• ./build/test-runner parallel go_lsp — 125 passed, regression fixtures dispatch as expected
• ./scripts/build.sh clean production build

Verified scope

• Synthetic two-package Go fixture: 49/49 handler→service field-chain calls resolve at 0.95 confidence via type dispatch (previously fuzzy match 0.33).
• Known gap, separate issue: the same calls regress to fuzzy match when the module is indexed nested inside an umbrella monorepo root (receiver-QN reconstruction from nested module dirs), and calls through generated client factories (service-guard structs) still yield no cross-service edges.

[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.

[DeusData]

Reviewed against current main. The core of this is good and not superseded — but one hunk now is, and main moved under you about an hour ago, so here is exactly where things stand.

You and #1940 independently found the same extraction bug

Your defect 2 — "every Go struct registered with zero fields" — was also diagnosed and fixed in #1940, which merged as 61de19bb while this was open. Two people arriving at the same root cause from different directions is corroboration, not duplication, and it is worth recording that you got there independently.

Concretely, extract_class_fields on main now reads:

TSNode body = find_class_member_body(class_node, ctx->language);
if (ctx->language == CBM_LANG_GO) {
    body = go_normalize_struct_body(body);   /* struct_type -> field_declaration_list */
}

So please drop your internal/cbm/extract_defs.c hunk. It is not a conflict — git will merge it cleanly, which is the problem. By the time your block runs, body is already the field_declaration_list, so your strcmp(ts_node_type(body), "struct_type") == 0 can never be true and the hunk lands as dead code that reads like a live second fix.

The rest of it is still needed — I checked rather than assumed

pxc_map_label in src/pipeline/pass_lsp_cross.c on main today admits type-like labels plus Protocol, Function, Method and Variable — and still not Field. So your premise holds exactly as written: the flat Field defs #1940 now produces are dropped on the way into the cross-file registry, and pxc_fold_go_struct_fields is what makes them reachable. #1940 created the nodes; this makes them usable. The two are complementary, and this half does not become redundant.

The go_lsp.c field-chain walk and go_requalify_via_imports are likewise untouched by anything that landed.

Two smaller asks

1. Take yourself up on the offer and drop the tracing commit (chore(go): add env-gated dispatch tracing). You flagged it as separable, which was the right call — a debugging facility is a change with its own lifetime, and bundling it means the review of the fix has to carry it. Happy to look at it as its own PR.
2. Rebase onto current main after dropping the hunk, so the diff shows only what is genuinely yours.

Worth calling out

The measurement is the part that makes this reviewable: 49/49 handler→service field-chain calls at 0.95 via type dispatch against 0.33 fuzzy, on a named fixture. And you recorded the two known gaps — nested-module receiver-QN reconstruction, and generated client factories — instead of leaving them for someone to discover later. That is the right way to hand over a partial fix.

Ping when it is rebased and I will re-review promptly.