[linhdmn]

The v4.19 reconcile made the two projects it touched report possibly_stale. The signal was lying about a store the reconcile had just made more correct.

Cause. Freshness is derived, not asserted (internal/store/backend.go:319-336): the inventory's seq is compared with the write watermark, and a difference reads possibly_stale. A delete advances that watermark — DeleteByFile and DeleteFileRecord both call BumpWatermark() — so the reconcile moved the watermark and left the inventory behind. The fleet doctor's own hint was then "re-index the stale projects", for stores that were exactly as fresh as they had been a minute earlier.

Measured on the live fleet (the wave's first pass, from the serve log):

maintain: 1 pass(es) over 20 store(s): reclaimed 1228800 bytes, grew 0 bytes, pruned 189 metric row(s)
  and 19 embed-run row(s), closed 0 stuck run(s), compacted the FTS index of 0 store(s),
  reconciled 6 stale file(s) (67 element(s)) with HEAD

and the next doctor run reported agentloop: current, possibly_stale and x-trader: current, possibly_stale — the two projects the reconcile had just touched. Both were fresh before.

Fix. The reconcile refreshes the inventory when it has deleted content (store.RefreshInventory), exactly as the core layer does after an index: the summary of what the store holds must match the store.

Tests

internal/maintain/reconcile_inventory_test.go — both fail on origin/main:

--- FAIL: TestReconcileKeepsTheStoreFresh
    the store reports "possibly_stale" after the reconcile, want "fresh" — a reconciled store is not a stale one
--- FAIL: TestReconcileRefreshesTheInventoryCounts
    the inventory says 2 elements, the store holds 1

and both pass with the fix. go build -p=2 ./..., go vet, gofmt clean; go test ./internal/maintain/ ./internal/store/ ./internal/core/ green.