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_test.go

@@ -35,6 +35,7 @@ func TestTransitionValid(t *testing.T) {
 		{StatusResolving, StatusDownloading},
 		{StatusDownloading, StatusVerifying},
 		{StatusVerifying, StatusOrganizing},
+		{StatusVerifying, StatusResolving}, // integrity retry: re-download after a failed on-disk verify
 		{StatusOrganizing, StatusCompleted},
 	}
 
@@ -60,7 +61,6 @@ func TestTransitionInvalid(t *testing.T) {
 		{StatusClaimed, StatusCompleted},
 		{StatusCompleted, StatusDownloading},
 		{StatusFailed, StatusCompleted},
-		{StatusVerifying, StatusResolving},
 	}
 
 	for _, tt := range invalid {