[exKAZUu]

Why

A variable-arity parameter parses its type, modifiers, and ellipsis annotations as unlabelled children. Queries such as (spread_parameter type: (_) @type) are rejected, so consumers cannot select these parts by field as they can for an ordinary parameter's type.

Requirements

• required: Improve the fork grammar using unresolved fork issues and useful major upstream changes, without preserving backward compatibility.
• required: Avoid duplicate work and give each independent improvement its own PR based on the latest main branch.
• required: Run review-booster and complete-pr concurrently, then merge, publish, and verify the release.
• chosen: Expose the type, modifiers, and ellipsis annotations through fields on spread_parameter, because those syntax roles otherwise require positional child inspection.
• chosen: Keep the binding under variable_declarator, because its existing name field already provides a working query and this improvement needs no new binding structure.

Customer Summary

Structural queries can select the type, modifiers, and ellipsis annotations of Java varargs parameters directly by field.

Technical Summary

spread_parameter labels its existing children with type, modifiers, and repeated annotations fields. A public WASM API regression parses plain and annotated variable-arity parameters and checks field access, query captures, binding names, and source ranges.

Testing

The complete annotated fixture compiles cleanly with JDK 27. Baseline native and public WASM probes reject all three missing field queries; the binding-name query already works. bun run build/ci, bun run verify, and bun wb test test/unit/varargsFields.test.ts test/unit/corpus.test.ts test/unit/wasm.test.ts pass. Both native and WASM execution pass all 165 corpus cases. A public API probe inserts and removes an ellipsis annotation twice, comparing field values and query captures/ranges with fresh parsing. Full verification and robustness CI passed on all configured platforms on the reviewed head.