manage_adr data loss on INCREMENTAL re-index (regression of #516)

[eazene]

Summary

manage_adr content is silently destroyed by an incremental re-index. This is a regression of the fix for #516: that fix preserves the ADR across the full re-index path, but the incremental path (taken whenever a prior DB + file hashes exist, i.e. after any edit) branches before the ADR snapshot and rebuilds the DB with no ADR capture.

Because the background watcher triggers an incremental re-index within ~5–60s of any git change, an ADR cannot survive normal development.

Reproduction (v0.9.0, darwin-arm64, official release binary)

$ index_repository (full)          -> creates DB + file hashes
$ manage_adr(mode=update, content="# ADR ... must survive")
$ manage_adr(get)                  -> {"content":"# ADR ... must survive"}   ✅
$ <append one line to any tracked file>
$ index_repository                 -> takes the INCREMENTAL route
$ manage_adr(get)                  -> {"content":"","status":"no_adr"}        ❌ lost

Self-contained script: https://github.com/ (available on request) — it inits a temp git repo, indexes, stores an ADR, appends one line, re-indexes, and shows no_adr.

Likely cause

The full-reindex path snapshots the ADR before deleting the DB (the #516 fix, pipeline.c:1137-1152). The incremental route branches earlier (pipeline.c:1125); dump_and_persist in pipeline_incremental.c unlinks and rebuilds the DB with no equivalent ADR snapshot/restore (grep -i adr pipeline_incremental.c returns nothing).

Suggested fix

Mirror the #516 snapshot/restore into the incremental dump_and_persist path (or hoist the ADR snapshot above the full/incremental branch so both routes are covered).

Impact

Silent, unrecoverable data loss of user-authored architecture notes during ordinary editing. Suggest either fixing the persistence or, until fixed, documenting that manage_adr is not durable.

[DeusData]

Thanks for the deterministic incremental data-loss reproduction. This is a high-priority 0.9.1-rc durability bug under #391. PR #992 appears intended to address this exact incremental ADR path, but we will verify your RED sequence against that exact head before treating it as fixed or closing this issue.