fix(graph): tombstones are terminal — re-derivation cannot resurrect facts

[alpertarhan]

Fixes #66.

Root cause

markFactStatus writes the resolved/superseded tombstone onto the same deterministic row id (stableId(projectId, sessionId, kind, factKey, branchHeadId)) that the ingest path computes for the same fact. But the write path's dedup check, sameActiveFact, requires row.status === "active" — a tombstoned row never matches, so the next compaction that re-derived the same content from the transcript hit the ON CONFLICT(id) DO UPDATE SET status = excluded.status upsert and flipped the fact back to active.

Net effect: /smart-compact loops resolve (and extraction-driven resolves) silently undid themselves on the next pass.

Fix

Both ingest write paths — addFact and the open-loops block — now fetch the latest lineage fact once and, in addition to the existing active-dedup check, skip the write when the latest lineage fact is non-active and the incoming node is active:

• tombstones (resolved/superseded) are terminal for their lineage
• writes that themselves carry a non-active status (extraction resolving a loop, factOverrides) are unaffected
• sibling branches keep their isolation — the check goes through latestLineageFact, which already ranks by branch lineage

Semantics note

Content-addressed factKey cannot distinguish a genuine recurrence from a transcript echo. This PR deliberately makes resolve terminal per lineage; re-opening requires an explicit override (a future unresolve), not passive re-ingest. This is also the foundation #63's forget needs — deletion must not be resurrectable through the same path.

Verification

• 987 tests (2 new: resolved error re-derived as unresolved stays hidden; resolved loop re-reported as open stays hidden), bench, build, release audit — all green