Fix split detection and application: case-sensitive matching and integrity checking

[Copilot]

The split detection service had multiple issues preventing detected splits from being applied to pages:

1. Saving all detection results (including images with zero splits) and unconditionally enqueuing apply tasks
2. Case-sensitive filename matching causing splits to fail when filenames had different casing
3. No integrity validation to detect when splits were marked as applied but weren't actually split

Changes

SplitProcessingService.ProcessDetectionResultsAsync

• Filter detection results before saving: only persist findings where Splits.Count > 0
• Only enqueue ApplySplitsTask when actual splits exist (resultsWithSplits.Count > 0)
• Preserve upscaling workflow when no splits detected but upscaling is configured

SplitApplicationService.ApplySplitsAsync

• Fixed case-sensitive filename matching bug that prevented splits from being applied
• Changed filename comparison from == to StringComparison.OrdinalIgnoreCase
• Made splitPagesMap and splitPagesToUpscale dictionaries use StringComparer.OrdinalIgnoreCase

LibraryIntegrityChecker.CheckSplitIntegrity (new)

• Validates split processing state consistency:
  • Status "Applied" with no split findings → Resets to Detected
  • Findings exist but LastProcessedDetectorVersion is 0 → Corrects status
  • Status "Applied" but split parts missing from archive → Re-enqueues split application
• Verifies splits were correctly applied by checking for _part1, _part2 suffixes in CBZ archives
• Automatically corrects mismatches and re-processes when needed

Tests Added

• SplitProcessingServiceTests.cs (4 tests) - Validates filtered saving and conditional task enqueueing
• SplitApplicationServiceTests.ApplySplitsAsync_MatchesFindingsCaseInsensitively - Validates case-insensitive matching

Example

Before:

// Saved ALL results, including those with 0 splits
foreach (var res in results)
{
    dbContext.StripSplitFindings.Add(finding);
}

// Always enqueued apply task when in DetectAndApply mode
if (chapter?.Manga?.Library?.StripDetectionMode == StripDetectionMode.DetectAndApply)
{
    await taskQueue.EnqueueAsync(new ApplySplitsTask(chapter, detectorVersion));
}

// Case-sensitive matching (would fail if casing differed)
var finding = findings.FirstOrDefault(f => f.PageFileName == fileNameWithoutExt);

After:

// Only save results with actual splits
var resultsWithSplits = results.Where(r => r.Splits.Count > 0).ToList();
foreach (var res in resultsWithSplits)
{
    dbContext.StripSplitFindings.Add(finding);
}

// Only enqueue apply task when splits exist
if (resultsWithSplits.Count > 0)
{
    if (chapter?.Manga?.Library?.StripDetectionMode == StripDetectionMode.DetectAndApply)
    {
        await taskQueue.EnqueueAsync(new ApplySplitsTask(chapter, detectorVersion));
    }
}

// Case-insensitive matching (handles different casing)
var finding = findings.FirstOrDefault(f => 
    f.PageFileName.Equals(fileNameWithoutExt, StringComparison.OrdinalIgnoreCase)
);

Root Cause

The primary issue preventing splits from being applied was case-sensitive filename matching. When the detection model saved findings with filenames like "page001" but the actual CBZ contained "Page001.png", the case-sensitive comparison caused matches to fail, preventing splits from being applied even though they were correctly detected.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Splits that the model detects are not separated</issue_title>
<issue_description>Some images where the model detects splits are currently not actually applied to the pages.</issue_description>

<agent_instructions>This is in regards to the functionality to split long concatenated images into the singular pages using manga-split-vert-nn.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Splits that the model detects are not separated #267

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Lolle2000la]

@copilot This seems like it might help if there are no splits, but can you also look at the following:

1. I manually looked at the results of the model using the gui_visualizer.py script in the manga-split-vert-nn repo and it DID detect breaks, but they were not applied in the software.
2. Can you also make the integrity checking check if a split was "applied" but there were no splits?
3. In addition to 2., can you see if the splits that were "applied" and if not, actually correctly split (assuming 1. is a bug)?

[Copilot]

@copilot This seems like it might help if there are no splits, but can you also look at the following:

1. I manually looked at the results of the model using the gui_visualizer.py script in the `...

I've addressed all three points:

1. Fixed the case-sensitive matching bug (commit 18dcb40)
The model was detecting splits correctly, but they weren't being applied due to case-sensitive filename matching. When the detection saves "page001" but the file is "Page001.png", the match failed. Fixed by:

• Using StringComparison.OrdinalIgnoreCase for filename comparisons
• Making dictionaries use StringComparer.OrdinalIgnoreCase

2. Added integrity checking (commit 6d7f769)
The LibraryIntegrityChecker now validates split state and detects:

• Status "Applied" with no split findings → Resets to Detected
• Findings exist but never marked as detected → Corrects status
• Status "Applied" but split parts missing from archive → Re-enqueues application

3. Split validation included
The integrity checker verifies splits were correctly applied by checking for _part1, _part2 etc. suffixes in the archive. If splits are marked as applied but the parts aren't found, it automatically re-enqueues the split application task.

These changes should resolve the issue where the model detects breaks but they aren't applied.