Semantic results with edges but no nodes are cached, permanently freezing the file out of the graph

[pureoption]

Summary

When a dispatched file's semantic result contains edges but no nodes (model omission), the empty entry is written to cache/semantic/ keyed by content hash — so every subsequent run is a cache hit and the file is permanently frozen out of the graph. The console warning says "a re-run will retry them", but the cache makes that false.

Environment

graphifyy 0.9.16, Python 3.12 (WSL2 Ubuntu 24.04), gemini backend, markdown corpus.

Mechanism

1. On large batches the model routinely omits files from its response — observed warning rates of 6/20, 5/8, 8/9, 9/15 dispatched file(s) produced no nodes.
2. A file with no output at all gets no cache entry and correctly re-queues (Files in failed semantic chunks are permanently skipped on re-run #933 handling).
3. But a file that received only edges (nodes list empty) does get a by_file entry in save_semantic_cache — cached as {"nodes": [], "edges": [...]}.
4. Every later run: content hash unchanged → cache hit → never re-dispatched. Observed: a corpus's most-referenced hub document sat at 0 nodes indefinitely; every edge pointing into it dangled and was pruned.
5. It cannot be healed from the outside either: other files' extractions that mention it are discarded by the allowed_source_files guard, and evicting the cache entry alone is not sufficient because _detect_incremental still reports the file unchanged (the manifest entry must be removed too).

Suggested fix

In save_semantic_cache, skip writing any per-file entry whose nodes list is empty — the file then stays uncached and genuinely re-dispatches on the next run, making the existing "a re-run will retry them" behavior true. We run 0.9.16 with exactly that patch (a warnings.warn on the skip); unit-verified that the edges-but-no-nodes shape no longer caches while normal results cache unchanged.