recall: with_open reuse guard misses store replacement, so a cached handle can point at a deleted inode

src/core/retriever.rs caches one SQLite connection per thread and reuses it when the path is unchanged and still exists:

let reuse = matches!(&*cache, Some((p, _)) if *p == path && path.exists());

path.exists() catches deletion but not replacement. If the store is deleted and recreated (a manual rm then a later run, a restore from backup, a second checkout writing the same path), the cached handle still points at the old inode. Reads then resolve against a file nobody can see, so a hash printed in scrollback stops resolving with no error.

Suggested fix: compare device+inode (std::os::unix::fs::MetadataExt) rather than mere existence, or drop the cache when the file's identity changes.

Surfaced during review of #3278; not introduced by it.

Start in src/core/retriever.rs at the per-thread connection cache and its path.exists() reuse guard. Check how the cached handle is retained when the store is deleted and recreated, then use the issue's device-and-inode approach or drop the cache when file identity changes. Done means a recreated store does not reuse a handle for the deleted inode and subsequent reads resolve normally.