Summary

Issue #2037 diagnosed a wrong-child-index bug in both engines' rest-pattern
identifier extraction for dynamic-import()/CJS-require() name
collection: rest_pattern's child(0) is the ... token, not the bound
identifier, so const [a, ...rest] = fn()-style destructures silently
dropped rest.

By the time this was investigated, the exact locations #2037 cited had
already been fixed — PR #2052 (merged 2026-07-11, closing #1920) fixed
extract_rest_identifier (Rust) and extractDynamicImportNames (TS) for
both array- and object-pattern dynamic import() destructures, in both
engines, three days after #2037 was filed. Verified via cargo test/
vitest (all existing #1920 regression tests pass) and a direct repro:
const [a, ...rest] = await import('./mod.js') already extracts
["a", "rest"] in both engines.

What was still actually broken, discovered while chasing #2037's own
CJS-require() repro (const { a, ...rest } = require('./mod')): the
Rust require() path reuses the already-fixed collect_object_pattern_names
helper directly, so it was already correct — but the TS/WASM require()
path uses a separate, never-fixed function, extractCjsRequireBinding,
whose object-pattern loop only recognized shorthand_property_identifier_pattern
and pair_pattern children. It had no rest_pattern/rest_element branch
at all, so rest was silently dropped from cjsRequireBindings (the
CJS-require import-artifact classification, #1661) — a genuine, currently
existing engine-parity gap.

Fix

• src/extractors/javascript.ts: added a rest_pattern/rest_element
  branch to extractCjsRequireBinding, reusing the existing
  extractRestPatternIdentifier helper (the same one extractDynamicImportNames
  already uses) — mirrors Rust's collect_object_pattern_names behavior.
• crates/codegraph-core/src/extractors/javascript.rs: no logic change
  needed (already correct) — added a regression test locking in the
  already-correct native behavior for the same repro, to prevent
  future regressions and keep the two engines' test coverage symmetric.
• tests/parsers/javascript.test.ts: added #2037 coverage for the
  CJS-require rest-binding case (plain + renamed-pair mixes).

Repro confirmation

Both engines now agree for both of the issue's repros:

const [a, ...rest] = await import('./mod.js')   -> names: ["a", "rest"]   (already correct, both engines)
const { a, ...rest } = require('./mod')         -> names: ["a", "rest"]   (native already correct; WASM fixed here)

Verified via codegraph diff-impact --staged -T — change is scoped to
extractCjsRequireBinding (6 transitive callers, 1 file).

Test plan

• npx vitest run tests/parsers/javascript.test.ts — 290 passed
• npm test — 273 files, 4424 passed, 30 skipped, 2 todo, 0 failed
• cargo test --lib (crates/codegraph-core) — 749 passed, 0 failed
• npm run lint — clean
• node scripts/parity-compare.mjs --langs javascript,typescript — PARITY OK, wasm vs native identical for both fixtures
• npx vitest run tests/benchmarks/resolution/resolution-benchmark.test.ts — 206 passed

Follow-up

Filed #2268 for an out-of-scope finding discovered during investigation:
both engines' CJS-require import-artifact classification only handles
object-pattern destructures, never array-pattern ones (symmetric gap, not
a parity divergence).

Closes #2037