feat(infra): playlist processing saga + generalize fault handling (phase 3)

Adds the PlayList picture-processing lifecycle saga (correlated by PlayListId)
mirroring the track one, and generalizes the failure plumbing:
- Rename the track fault translator to ProcessingSlipFaultConsumer and use a
  generic Workflow.SubjectId variable + ProcessKind; it now emits typed
  Track{Picture,Audio}/PlayListPicture ProcessingFailed events for all slips
- PlayListProcessingStateMachine (+ EF-persisted PlayListProcessingState,
  migration): starts on CreatePlayListResourcesEvent, finalizes on
  PlayListPictureProcessed, and on failure marks the playlist Failed and
  removes the orphaned final picture (PlayListProcessingFailedConsumer +
  MarkPlayListAsFailedActivity)
- UpdatePlayListPictureActivity publishes PlayListPictureProcessed on success
- Picture slip carries SubjectId + PlayListPicture kind + fault subscription

Verified end-to-end in Docker (RabbitMQ + migrated Postgres): both saga
endpoints, the fault translator and cleanup consumers configure, and an
addressing cross-check confirms all 21 activity execute queues the builders
address exist (caught + fixed a kebab mismatch on mark-play-list-as-failed).

Build: 0 warnings, 0 errors.

backend/Musify.Infrastructure/Persistence/Database.cs

@@ -30,6 +30,11 @@ namespace Musify.Infrastructure.Persistence
             trackProcessing.HasKey(state => state.CorrelationId);
             trackProcessing.Property(state => state.CorrelationId).ValueGeneratedNever();
             trackProcessing.Property(state => state.CurrentState).HasMaxLength(64);
+
+            var playListProcessing = modelBuilder.Entity<PlayListProcessingState>();
+            playListProcessing.HasKey(state => state.CorrelationId);
+            playListProcessing.Property(state => state.CorrelationId).ValueGeneratedNever();
+            playListProcessing.Property(state => state.CurrentState).HasMaxLength(64);
         }
 
         public DbSet<User> Users => Set<User>();