Trust only uploaded blobs for deduplication (closes #148)

An interrupted blob upload left the blob's chunks, blob_chunks, and
blobs rows committed before the upload was attempted, so a later run
deduplicated against data that never reached storage and produced a
snapshot that reported success but could not be restored.

Chosen fix (issue option b): a chunk counts as known only when a blob
holding it has uploaded_ts set, and each run drops un-uploaded blob
rows and the chunks they orphan at startup, so the affected data is
re-chunked and re-uploaded. Option a (withholding all row writes until
the upload succeeds) would entangle the packer's writes with upload
ordering; gated reads plus a startup repair is smaller and self-healing.

Blobs recorded with no remote backend are marked uploaded so the
invariant holds uniformly.

model: claude-opus-4-8

TODO.md

@@ -25,6 +25,19 @@ release" is exactly the contradiction
 
 # Completed Steps
 
+- 2026-09-21: Stopped an interrupted blob upload from making a later
+  backup deduplicate against data that was never stored
+  ([issue #148](https://git.eeqj.de/sneak/vaultik/issues/148)). The
+  packer commits a blob's `chunks`, `blob_chunks`, and `blobs` rows
+  before the upload is attempted, so a failed upload left chunk rows
+  behind and the next run skipped re-uploading them, producing a
+  snapshot that reported success but could not be restored. A run now
+  deduplicates only against chunks held by a blob whose `uploaded_ts` is
+  set, and at startup drops any un-uploaded blob rows (and the chunks
+  they orphan) so the affected data is re-chunked and re-uploaded. Blobs
+  recorded with no remote backend are marked uploaded so this invariant
+  holds uniformly.
+
 - 2026-09-21: Stopped `prune` from reporting a failed row count as 0
   ([issue #96](https://git.eeqj.de/sneak/vaultik/issues/96)). The seven
   `getTableCount` reads in `PruneDatabase` discarded their error, so a