fix(jobs): flush the checkpoint tail, so progress reflects reality

All three import jobs only checkpointed on a full batch, so the
remainder after the last one was never counted. A run shorter than
BATCH_SIZE never checkpointed at all: `scanned_count` stayed 0 against
a known `total_rows`, and the admin progress bar sat at zero for the
whole run and finished there.

Seen on a transcode_import run over 20 entries — 13 imported, 5
negatives, 2 already present, progress 0/20 throughout. The thumbnail
imports had it too, just less visibly: a 105-file run reported
`scanned_count: 100`, losing the tail rather than all of it.

Cursor-wise the final checkpoint is a no-op — the walk is finished, so
nothing resumes from it — but the scanned delta is what the progress
display reads, and it has to include the last partial batch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/infrastructure/services/thumb_attached_import_service.rs

@@ -476,6 +476,18 @@ impl RecoverableJobHandler for ThumbAttachedImport {
             }
         }
 
+        // Flush the tail — see the derived twin. The loop only checkpoints
+        // on a full batch, so the remainder went uncounted: a 105-file run
+        // reported `scanned_count: 100`, and a run shorter than one batch
+        // reported zero and left the progress bar at zero throughout.
+        if since_checkpoint > 0
+            && let Err(e) = store.checkpoint(Vec::new(), since_checkpoint as u64).await
+        {
+            return RunOutcome::Failed {
+                message: format!("final checkpoint: {e}"),
+            };
+        }
+
         // Both jobs attempt the teardown, and it no-ops unless the tree is
         // drained of files EITHER of them claims. Without this, whichever
         // job runs last leaves an empty `.thumbnails/` behind until the