Engine parity: native JS extractor emits no definition for const array-pattern destructuring

[carlos-alm]

Summary

For a top-level const [a, b] = someCall(); declaration, the WASM/TS extractor and the native Rust extractor disagree:

• WASM (src/extractors/javascript.ts, both the walk path in handleVariableDeclarator and the query path in extractDestructuredDeclarators): emits a single Definition with kind: 'constant', whose name is the literal source text of the whole pattern (e.g. "[a, b]" as one node — not per-element a/b).
• Native (crates/codegraph-core/src/extractors/javascript.rs, handle_var_decl): emits nothing at all for array_pattern name nodes in a const declaration — there is no array_pattern branch in handle_var_decl, only in extract_dynamic_import_names/collect_array_pattern_names (a completely separate code path used only for const { a, b } = await import(...) name extraction, which returns bare name strings, not Definition structs).

Evidence

Fixture (sample.js):

function getArr() { return [1, 2]; }
const [a, b] = getArr();

WASM (--engine wasm) where --file output includes:

{ "name": "[a, b]", "kind": "constant", "line": 3 }

Native (--engine native) where --file output for the same file: no [a, b] node at all — 8 nodes total vs WASM's 9.

Where this was found

Discovered while investigating issue #1773 (destructured object-pattern bindings misclassified as kind: "function"). The object-pattern bug is fixed in that issue's PR; this array-pattern parity gap (not a kind-misclassification — a totally missing definition on the native side) is a separate, pre-existing bug and is out of scope there.

Note: the WASM code's own comment claims the single-constant-node behavior is "matching native engine behaviour" (see src/extractors/javascript.ts, added in commit 3b5ab14f9) — that claim is incorrect; native does not currently replicate this at all.

Suggested fix

Per CLAUDE.md's dual-engine parity mandate, decide the correct shared behavior (likely: extract each bound identifier in the array pattern as its own constant-kind Definition, superseding the current WASM "one node named by raw pattern text" approach, which itself is not very useful for querying/resolution since [a, b] is not a real identifier) and make both engines match it exactly.