Apply one low-risk Rust indexing performance optimization

[jununfly]

Parent

Phase 2 plan: docs/plans/2026-06-13-rust-indexing-core-phase-2-packaging-ci-performance.md

What to build

Use the new profiling evidence to make one low-risk Rust indexing performance improvement without broadening language scope or changing the default TypeScript path. The optimization should target the measured bottleneck rather than speculative rewrites.

Acceptance criteria

• The chosen optimization is justified by profiler output from this repository or Excalidraw.
• The change preserves JS/TS/JSX/TSX semantic output and failure safety.
• Regression coverage is added if observable output, indexing counts, or failure behavior changes.
• Default TypeScript indexing behavior remains unchanged.
• Peak RSS does not materially regress from the Phase 1 memory-control result.

Blocked by

• Add Rust indexing phase profiler #66

[jununfly]

Implemented in 85decc7. Chose SQLite write batching based on the #66 repository profile: sqliteWriteMs dominated Rust-side time. Rust core now writes indexed files inside one SQLite transaction, with regression coverage for symbol-heavy projects, semantic parity validation, default TypeScript path validation, and local profile/benchmark checks. Verified with npm run build, cargo fmt --package zcodegraph-core -- --check, cargo test --package zcodegraph-core, npx vitest run tests/rust-parity.test.ts, npx vitest run tests/rust-index-engine-cli.test.ts -t 'uses the TypeScript indexer by default', node scripts/rust-index-profile.mjs --repo zcodegraph=., and node scripts/rust-index-benchmark.mjs --repo zcodegraph=. (RSS sampling run outside sandbox).