Summary

• extractDestructuredBindings (TS/WASM) and its mirror extract_destructured_bindings (native) only recognized shorthand_property_identifier_pattern and pair_pattern children when creating constant-kind Definitions for a plain object-destructuring const declaration, so:
  • const { a, ...rest } = someValue; never got a Definition for rest.
  • const { a = 1 } = someValue; never got a Definition for a at all.
• Verified present identically in both engines — a genuine parity-preserving gap, not a WASM-only bug.
• Fixed by adding object_assignment_pattern (default value) and rest_pattern/rest_element branches to both engines, mirroring the equivalent fix already landed for extractDynamicImportNames/extract_dynamic_import_names in WASM dynamic-import destructure extraction misses rest/default-value bindings that native engine handles #1920 (PR fix(extractors): extract rest/default bindings from dynamic import() destructures #2052). The TS side reuses the existing shared extractRestPatternIdentifier helper; the Rust side reuses the existing extract_rest_identifier helper.
• Both the walk-based and query-based paths call the same shared extractDestructuredBindings/extract_destructured_bindings function, so both are fixed by this one change.
• Checked the array-pattern counterpart (extractArrayPatternBindings/extract_array_pattern_bindings) for the same class of bug per the issue's broader "destructured-binding" title — it already correctly handles both assignment_pattern (default) and rest_pattern/rest_element in both engines (added in Engine parity: native JS extractor emits no definition for const array-pattern destructuring #1901), so no change was needed there.

Repro (issue's own example)

const { a, ...rest } = someValue;
// before: definitions contains `a` but not `rest`
// after:  definitions contains both `a` and `rest`, kind 'constant'

const { a = 1 } = someValue;
// before: definitions does not contain `a` at all
// after:  definitions contains `a`, kind 'constant'

Confirmed via a real buildGraph() run against a small fixture on both engine: 'wasm' and engine: 'native' (native addon rebuilt + codesigned locally) — both produce identical constant definitions: a, d, rest, someValue.

Test plan

• npx vitest run tests/parsers/javascript.test.ts — 291 passed (3 new, covering rest/default/mixed bindings in object-pattern destructured const declarations)
• cargo test --lib javascript (crates/codegraph-core) — 216 passed (3 new, mirroring the TS cases)
• Rebuilt and codesigned the native addon locally (npx napi build --platform --release + codesign --sign - --force) so the fix was exercised by the real native engine
• npm test — full suite: 273 files, 4427 passed, 30 skipped, 2 todo, 0 failed
• npm run lint — clean
• node scripts/parity-compare.mjs --langs javascript,typescript,tsx,pts-javascript,dynamic-javascript,dynamic-typescript --hybrid — PARITY OK, all engines identical across all 6 JS/TS-related fixtures
• npx vitest run tests/benchmarks/resolution/resolution-benchmark.test.ts — 206 passed, javascript/typescript/pts-javascript all at 100% precision/recall
• codegraph diff-impact --staged -T — confirms the change is scoped to exactly extractDestructuredBindings, 6 transitive callers, all within the JS/TS extractor

Closes #2051