Fix data loss when importing a book matched to the wrong file.

[nightah]

Database Migration

NO

Description

Fixes a data-loss path: importing a book can permanently delete an unrelated book's file. Reported in #173, reproduced here with debug/trace logs, and fixed in four independent commits (each stands alone, split them if you prefer).

What happens. A file whose tags carry an unusable identifier is matched to the wrong book, and the next import for that book deletes it as an "upgrade":

bookFileImported bookId=3 | Ana Huang - Twisted Games
bookFileDeleted  bookId=3 | /books/Ana Huang/Twisted Lies/Twisted Lies - Ana Huang.azw3 | reason=Upgrade

With no Recycle Bin configured RecycleBinProvider deletes permanently, which is the loss reported in #173.

Why the file was mis-matched. Calibre writes its internal UUID into the MOBI/AZW3 EXTH ASIN record (113). DistanceCalculator reads it as an ASIN and compares it to the edition ASIN at weight 10.0, while a wrong title costs only 3.0 and a missing identifier 0.1. The correct book therefore scores worse than a different book by the same author that has no ASIN at all:

[30913880][Twisted Lies]   book: exact match      asin: UUID vs B09TVV9NH2 -> 0.3855
[30704937][Twisted Games]  book: MISMATCH         asin: UUID vs ''         -> 0.0644   <- chosen

8 of 24 Kindle-format files in the library I reproduced this on carry such a UUID, produced by five different Calibre versions, so this is not a one-off.

Commits

1. fix(identification): ignore malformed ASIN/ISBN values from file tags - validate the identifier from file tags before using it; a malformed value is treated like a missing one.
2. fix(identification): treat a differing ISBN/ASIN as unknown, not as a mismatch - editions of the same work legitimately carry different identifiers, and the metadata source often holds one the file does not. Reward a match rather than punish a mismatch, so an identifier can promote the right edition but can no longer select a different book.
3. fix(import): never delete an existing file outside the destination folder - the actual data-loss guard. UpgradeBookFile deleted every BookFile row attached to the book, wherever it lived. Now only files in the folder the incoming file will occupy are replaced; anything else is left on disk, detached from the book and warned about, and the next scan picks it up as an unmapped file. If the destination cannot be calculated the old behaviour is kept, so imports are never blocked. Calibre libraries are unaffected.
4. fix(manualimport): guard null ImportItem when cleaning up download folders - ManualImport threw a NullReferenceException after importing successfully when the tracked download came from the client's history rather than a grab.

Todos

• Tests
• Translation Keys - not needed, no user-facing strings added
• Wiki Updates - not needed

Notes for reviewers

• Behaviour change in commit 3. If a book's folder is renamed upstream (a title change), an existing file in the old folder is no longer deleted on the next import; it is detached and left on disk, then re-imported by the next scan as an unmapped file. That seemed the right trade against deleting an unrelated book. Happy to gate it behind a config option instead.
• replaceExistingFiles is dead. The flag is plumbed from the manual import API through ImportApprovedBooks but its only consumer, RemoveExistingTrackFiles, is commented out at ImportApprovedBooks.cs:128-131. Passing false does not prevent existing files from being deleted. Not touched here - it deserves its own decision: implement it or remove it from the API.

Issues Fixed or Closed by this PR

• Fixes Import of one book deletes unrelated book's file (no recycle bin fallback = permanent data loss) #173