fix(engine): cross-backend integrity guard with retry-then-damaged

A truncated debrid download (in-memory byte counter hit 100% while the
NFS write-back silently dropped most of the bytes) was marked completed.
The 1.1.6 fsync fix closed the debrid-specific hole; this generalizes the
guarantee so "completed" never means a corrupt file on ANY backend.

- IntegrityError + bounded retry: on a corrupt/short result the manager
  re-downloads the same source up to 3x (clean start), then surfaces the
  task as damaged ("corrupt download:" prefix) instead of completing it.
- verify (size mismatch / empty), debrid (incomplete / post-write / flush),
  torrent (BytesMissing), usenet (par2 unrepairable / repair-failed) all
  classify integrity failures so they route through the retry/damaged path.
- scanner: a file ffprobe can't read is emitted as a damaged library_item
  (reason "unreadable") instead of being silently dropped from the sync.
- tests: manager retry-then-success + retry-exhausted-then-damaged,
  verifying->resolving transition, damaged sync item.

internal/engine/task.go

@@ -31,9 +31,11 @@ var validTransitions = map[TaskStatus][]TaskStatus{
 	StatusClaimed:     {StatusResolving, StatusCancelled},
 	StatusResolving:   {StatusDownloading, StatusFailed, StatusCancelled},
 	StatusDownloading: {StatusVerifying, StatusFailed, StatusResolving, StatusCancelled},
-	StatusVerifying:   {StatusOrganizing, StatusFailed},
-	StatusOrganizing:  {StatusSeeding, StatusCompleted},
-	StatusSeeding:     {StatusCompleted},
+	// Verifying → Resolving: the on-disk verify found a truncated/corrupt file and
+	// the manager is re-downloading the same source (bounded integrity retry).
+	StatusVerifying:  {StatusOrganizing, StatusFailed, StatusResolving},
+	StatusOrganizing: {StatusSeeding, StatusCompleted},
+	StatusSeeding:    {StatusCompleted},
 }
 
 // Task represents a download task with its full lifecycle state.