Fix SQL reference persistence and repeated statement scans

[Widthdom]

SQL indexing can fail while persisting @@ROWCOUNT, @@IDENTITY, and other system-variable references: the extractor emits system_variable, but the shared kind catalog rejects it. Register that existing kind so writer validation and SQLite CHECK constraints accept the extracted references. Existing databases use the current constraint-migration path, which preserves stored rows.

Repeated seed-data statements also accumulate and rescan all prior statement text when semicolons are absent, including across GO separators. Clear that text at standalone batch separators and conservative independent INSERT/UPDATE/DELETE boundaries. Preserve compound WITH/MERGE/CREATE context, nested expressions, upsert continuations, and temporary-object names.

Validation

• Reproduced the persistence failure before the fix with SELECT @@ROWCOUNT; and failing extraction/CLI regression tests.
• Passed 231 focused tests on each of .NET 8 and .NET 9 in Release, covering SQL extraction and graph queries, kind validation, existing constraint migration, fresh/full/scoped indexing, and ordinary/native reference persistence.
• Indexed a synthetic fixture containing 10,000 UPDATE statements and system-variable references in approximately 2.2 seconds, with zero errors and complete index/reference-graph readiness.
• dotnet build --no-restore: passed with no warnings or errors.
• make lint: passed.
• dotnet run --project tools/CodeIndex.Changelog -- check: passed.
• Repository status --check and workspace status --check: passed after rebuilding and refreshing the local index.
• Self-review: No blocking/actionable issues found.

Documentation

Updated the English/Japanese SQL persistence and statement-carry notes in DEVELOPER_GUIDE.md and the regression guidance in TESTING_GUIDE.md.

Changelog fragment: changelog.d/unreleased/+sql-reference-indexing.fixed.md.

Limits and follow-up

The original SQL files were not available. These are independently reproduced defects found while investigating a v1.51.0 error report; the exact cause of the reported five-minute E013_INDEX_EXTRACTION_STALLED remains unconfirmed. Verify the original files with the fixed binary. Normal indexing can update the existing database without deleting it or requiring --rebuild.