fix: skip unchanged canonical corpus chunks via stored content hashes

[benjaml4]

Fixes #981.

runSync() re-embedded and re-upserted every chunk on every sync — stats.skipped only counts errors, so there was no unchanged path. Each pass creates a new LanceDB version set, and runStorageMaintenance() clamps retention to ≥ 1 day, so on restart-heavy installs the store grew ~1GB per boot (76M → 9.2G here) with no same-day way to reclaim it.

The fix reads back what toMemoryEntry() already writes: corpus_content_sha256, bulk-loaded once per sync via the existing store.listCorpusEntryRefs(). Chunks whose hash matches are skipped (no embed, no upsert) but still land in expectedIds, so cleanupStaleCorpusEntries() behaviour is unchanged. Adds an unchanged counter to CorpusIndexStats and the completion log.

Measured across consecutive restarts on a real 2,505-chunk corpus:

before: indexed 2505/2505 every boot — store 76M -> 9.2G over a few restarts
after:  indexed 1, unchanged 2504   (one file genuinely edited)
after:  indexed 0, unchanged 2505   — store flat at 78M

Also saves 2,505 embedding calls per restart. tsc --noEmit clean. Independent of the #980 PR; both touch corpus-indexer.ts in non-overlapping regions.

[rwmjhb]

Reviewed head 781f344. Changes requested:

1. The full local suite is red at test/corpus-indexer.test.mjs:163: sync() now returns unchanged: 0, but the existing deepStrictEqual expectation still uses the old result shape. Please update that assertion and add a real two-sync regression that forces a second completed sync and proves there are no additional embedding/upsert calls, unchanged chunks remain in stale cleanup's expected set, and stats.unchanged is correct.

2. src/corpus-indexer.ts:611 skips solely on chunk ID plus text hash, while the stored row also carries corpus_start_line, corpus_end_line, corpus_chunk_count, document hash, mtime, and timestamp. An edit elsewhere in a document can preserve a chunk's index/text while shifting its line range, leaving citations built from the stored metadata stale. Please include retrieval-relevant metadata in the comparison, reindex all chunks when the document fingerprint changes, or refresh metadata while retaining the existing vector.

This head is also behind master and has no GitHub check runs, so please rebase and rerun the full suite with the regression coverage above.

[rwmjhb]

Re-reviewed at 1be4c49. The previous blockers are resolved: unchanged detection now requires both the chunk content hash and document hash, the result-shape assertions are updated, the forced second-sync regression covers the no-embed/no-upsert path, and the generated runtime artifact is committed. The branch is mergeable and all required CI checks are green.

Non-blocking follow-up: the document-edit fixture still changes both hashes at once, so a multi-chunk test that edits one chunk and asserts exact reindex/unchanged counts would more directly protect the document-hash-only path.