Captures() keeps only the last capture name's nodes, so any multi-name tree-sitter query silently loses matches

[rahlk]

Describe the bug

cldk/analysis/commons/treesitter/models.py:50-53 rebinds self.captures inside its loop instead of extending it:

def __init__(self, captures: Dict[str, List[Node]]):
    self.captures = []
    for capture_name, captures in captures.items():
        self.captures = [self.Capture(node=node, name=capture_name) for node in captures]

Every iteration discards the previous one, so a query with more than one capture name returns only the nodes of whichever name the dict yields last. A single-capture query is unaffected, which is why this has gone unnoticed.

The loop variable also shadows the parameter, which is what makes the bug hard to see on a quick read.

Any tree-sitter query in the SDK with two or more capture names silently returns a subset. TreesitterJava.get_calling_lines and get_methods_with_annotations both go through this type. It surfaced while investigating a call-line ordering divergence between the Java backends: the symptom looked like an ordering problem, but the cause is dropped captures.

Whether a caller sees wrong results today depends on how many capture names its query declares, so the blast radius needs checking per query rather than assumed.

To Reproduce

Not stated in the original issue.

Expected behavior

• The new test fails before the fix and passes after
• Any accessor whose results change is named in the CHANGELOG

Additional context

Scope boundary

In scope: the accumulation bug, the shadowed parameter, and an audit of every tree-sitter query in the SDK for how many capture names it declares. Out of scope: redesigning the tree-sitter layer.

Goals

• Captures accumulates across capture names
• The loop variable no longer shadows the parameter
• Every multi-capture query in the SDK is identified, and each one's behaviour before and after is stated
• A test with at least two capture names that fails on the current code