fix(importer): confirm deletes against the filesystem before they cascade

[ajslater]

Second of the fixes from the rename/move pipeline audit. This one is structural: it removes the consequence that made every other pairing bug in that audit permanent.

Prerequisite for the rename-first redesign that follows — that change deletes the tag-write guard registry, and this is what keeps its failure modes from costing bookmarks.

The pattern this fixes

Deleting a comic row cascades its bookmarks and read progress away, and nothing brings them back: the next scan re-imports the file as a fresh, unread comic. But both scanners infer deletes rather than observing them, and every inference has failure modes that name a path still sitting on disk:

• a watch batch carrying a delete whose paired add lands in the next batch (the 60s force-yield during bulk external activity)
• a directory expansion that overmatched
• an inode pair the size/type compatibility checks refused
• a file replaced in place, where the delete and the add arrive together

Each was a separate bug with a separate fix. The common ending was the same: a hard delete by path with no check that the file was actually gone.

Changes

Deletes are confirmed against the filesystem. Comics, folders and custom covers all check before deleting, and anything still on disk is left for the next scan. A stale row costs a re-read; a wrongly deleted one costs the user their place in the book.

A file replaced in place is re-read, not deleted. A path reported both deleted and added in one batch is reclassified as modified. The recreated file has a new inode so move detection can never pair it, and dedup previously let the delete win. The poller already reached this conclusion by diffing snapshots — this makes the watcher agree.

A mass delete is flagged. The backstop cannot save a library whose whole mount vanished, since every path then reads as missing. A delete large enough to look like that (≥50% of the library, ≥50 comics) logs where to go looking. Nothing is blocked.

Folder deletes re-stamp what they emptied. Comics under a deleted folder die by the parent_folder cascade rather than by path, so they never reached the collection capture: the series or publisher a folder delete emptied was never re-stamped and browsers kept listing comics that were gone. They were also counted as folders rather than comics.

Notes for review

• One existing test's fixture changed. test_unregistered_paths_are_untouched asserted an unrelated comic still deletes while leaving its file on disk — which is now precisely the case that is spared. It removes the file, so it tests guard scoping rather than passing for the wrong reason.
• Cost: one Path.exists() per deleted path (paths are already batched), and one count() per import that deletes comics. A path that is genuinely gone answers immediately.
• Not covered: an unmount is still destructive if the poller runs against a missing mount; the poller has its own guards for that and the watcher does not. That gap is tracked separately, and the new log line is the breadcrumb for it.
• Every new test was verified to fail against the old code. make lint, make ty, full pytest and vitest all pass.