Checkpoint semantic cache per chunk so interrupted runs resume

[A-Levin]

Problem

Semantic extraction only writes to the cache once, at the very end of the run — save_semantic_cache is called in __main__ after extract_corpus_parallel returns. on_chunk_done only prints progress; nothing is persisted per chunk.

So a run interrupted partway — a crash, a kill, a reboot, or a claude-cli/API run that exits when it hits a rate limit — loses every completed chunk and restarts from scratch. On a large corpus (thousands of files) with a slow local backend (e.g. Ollama), that can throw away many hours of completed work, and there is no way to make incremental progress across sessions.

Fix

Persist each chunk's semantic results to the cache as soon as the chunk completes, in both the serial and threaded paths of extract_corpus_parallel. On restart, check_semantic_cache already filters out cached files, so the run resumes where it left off.

To stay correct when a large file is split into slices across several chunks, save_semantic_cache gains a merge_existing flag: the checkpoint unions with any existing cache entry for a file instead of letting a later chunk overwrite an earlier slice.

• Best-effort: a cache write error never aborts extraction.
• Opt-out via GRAPHIFY_NO_INCREMENTAL_CACHE.
• Backward compatible: save_semantic_cache defaults to merge_existing=False (unchanged behaviour); the final end-of-run save is untouched.

Testing

• Existing suite green: test_cache.py (31), plus semantic tests (test_semantic_cleanup, test_zero_node_no_cache, test_word_count_cache, test_semantic_id_remap_root) — 35 more pass.
• Added functional check: two slices of the same file written with merge_existing=True accumulate (n1 → n1,n2); merge_existing=False still overwrites; check_semantic_cache then reports the file as cached (resume works).
• Verified live on a ~5000-file vault with the Ollama backend: cache entries now appear after the first chunk instead of staying empty until the run finishes.