Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="code/backend/Cleanuparr.Domain/Entities/Deluge/Response/DownloadStatus.cs" line_range="10" />
<code_context>
-    public string? State { get; init; }
-    
+
+    public DelugeState State { get; init; }
+
     public string? Name { get; init; }
</code_context>
<issue_to_address>
**issue (bug_risk):** Enum-based State with StringEnumConverter may throw on unexpected Deluge values instead of defaulting to Unknown.

Changing from a nullable string to a non-nullable enum improves the model, but with `StringEnumConverter` any new/invalid state value from Deluge will now cause deserialization to fail instead of flowing through. To keep behavior resilient to unexpected/protocol-changed states, consider a custom `JsonConverter` (or handler) for `DelugeState` that maps unknown strings to `DelugeState.Unknown` instead of throwing.
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- In `DelugeStateConverter.WriteJson`, consider emitting the exact wire format Deluge expects (e.g., lowercase strings and possibly `null`/omitted for `Unknown`) instead of `value.ToString()` in PascalCase, to avoid subtle integration issues if these states are ever sent back to Deluge or logged for debugging.
- The seeding filter in `DelugeServiceDC.GetSeedingDownloads` has become a bit dense with the combined `State` and `IsFinished` checks; extracting this into a small helper (e.g., `IsConsideredSeeding(DownloadStatus x)`) would make the business rules around seeding/finished/paused/queued states easier to understand and maintain.

## Individual Comments

### Comment 1
<location path="code/backend/Cleanuparr.Infrastructure/Features/DownloadClient/Deluge/DelugeServiceDC.cs" line_range="24" />
<code_context>
         return downloads
             .Where(x => !string.IsNullOrEmpty(x.Hash))
-            .Where(x => x.State?.Equals("seeding", StringComparison.InvariantCultureIgnoreCase) is true)
+            .Where(x => x.State is DelugeState.Seeding || x is { IsFinished: true, State: DelugeState.Paused or DelugeState.Queued })
             .Select(ITorrentItemWrapper (x) => new DelugeItemWrapper(x))
             .ToList();
</code_context>
<issue_to_address>
**suggestion:** The seeding filter mixes `State` and `IsFinished` in a single pattern; extracting this into a named predicate would reduce the risk of subtle logic mistakes.

This line now encodes three rules at once: always include `Seeding`, include `Paused` when finished, and include `Queued` when finished. While correct per the tests, it’s dense and likely to become fragile as states evolve (e.g., new states or `Unknown`). Extracting a named predicate such as `bool IsConsideredSeeding(DownloadStatus x)` (or an equivalent method on `DownloadStatus`) would make the intent clearer and centralize seeding semantics in one place.

Suggested implementation:

```csharp
            .Where(x => !string.IsNullOrEmpty(x.Hash))
            .Where(IsConsideredSeeding)
            .Select(ITorrentItemWrapper (x) => new DelugeItemWrapper(x))

```

To fully implement the suggestion, you should also introduce a dedicated predicate method that encapsulates the seeding semantics. For example, inside the `DelugeServiceDC` class (or wherever this query lives), add:

```csharp
private static bool IsConsideredSeeding(DownloadStatus x)
{
    if (x is null)
    {
        return false;
    }

    return x.State is DelugeState.Seeding ||
           x is { IsFinished: true, State: DelugeState.Paused or DelugeState.Queued };
}
```

Adjust `DownloadStatus` to the actual type of `downloads`’ elements if it differs. If nulls cannot appear in `downloads`, you can omit the null check. Centralizing the logic in this method makes the intent clearer and future changes to seeding semantics easier and safer.
</issue_to_address>