fix(go): extract Variables from grouped var ( ... ) declarations

[tthayer]

Problem

A parenthesized Go var block produces no Variable nodes:

var (
	A = 1
	B = "x"
)

tree-sitter-go nests these specs under a var_spec_list node. extract_vars_mainstream (internal/cbm/extract_defs.c, Go case) only reads direct var_spec/const_spec children, so it never sees them. Single var x = 1 works. const ( ... ) also works, because its const_spec children are direct (the grammar has no const_spec_list).

Anything keyed on package-level variables misses grouped declarations. Found while measuring #2452: wire.NewSet(...) provider sets declared inside a var ( ... ) block had no Variable source node.

Change

The Go case moves into two helpers, extract_go_vars and extract_go_spec, which read direct specs and also the children of each var_spec_list. The loops are flat because clang-tidy's misc-no-recursion rejects the recursive form. No other language is touched.

Test

go_grouped_var_specs_mint_variables in tests/test_extraction.c covers a var group, a const group and a single var. It asserts the names, the Variable label, the line ranges, and exactly 5 Variables.

• Before the fix: fails (d is NULL); extraction is 393 passed, 1 failed.
• After: extraction 394 passed.
• Full suite (darwin arm64, ASan+UBSan, every suite via --suites): 8305 passed, 0 failed, 10 skipped. No ledger or contract constants moved. That run used an earlier recursive version of the helper, rewritten flat for clang-tidy; after the rewrite, extraction, lang_contract and edge_structural were re-run: 469 passed.
• clang-format on changed lines, lint-tidy-diff and lint-memory-core.py: clean.

Not changed

Multi-name specs (var a, b = 1, 2) still record only the first name, because the code reads the single name field. That has a different cause.

Written with Claude Code (Anthropic). I reviewed the change and am accountable for it.

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

Thank you for separating this extraction fix from the Wire feature and for documenting the final helper rewrite and its rerun coverage. I checked the Go variable loop on current main: it handles direct var_spec/const_spec children. This is a focused bug-fix candidate independent of approving BINDS. The review queue is currently full, so a complete review may take a little time. Thank you for your patience and for helping improve the project; this acknowledgement is not yet an approval or a merge commitment.