fix(search): resolve indexers once per batch, read MinimumAge/MaximumSize, and fix a profile size overflow

[m4bard]

Summary

This PR now carries three fixes that all land in SearchResultScorer.cs and its partials, previously filed as three separate PRs: this one (#921), #863, and #985. #921 already said it would absorb #863 ("This conflicts with my own #863 in SearchResultScorer.cs... Whichever of the two lands first, I will rebase the other"), and #985 was carved out of #921's own work ("Found while wiring Indexer.MaximumSize in #921 and kept out of that PR as a separate bug"). Consolidating avoids two rebases of the same file for the same author, and #863 and #985 are being closed in favor of the commits here rather than abandoned; see the closing comments on each.

Change 1 (from #863): resolve indexers once per batch, not once per result in parallel

QualityProfileService.ScoreSearchResults fanned out with Task.WhenAll, and each task queried the same scoped IIndexerRepository, so a batch of N results issued N concurrent queries against one scoped DbContext. EF rejects a second operation on a context while another is in flight.

The scorer already caught that exception and logged it at Debug, so nothing failed outright. What it lost was indexerRetention, which stayed 0, and the branch that sets isNzb from the indexer's own type. Age and retention checks then scored the result against assumptions that did not match its indexer, and the batch came back plausibly ordered and quietly wrong.

ScoreSearchResults now resolves the batch's distinct indexers sequentially up front (ResolveIndexersAsync) and passes the lookup into SearchResultScorer, which prefers it over querying when present. The single-result ScoreSearchResult path is unchanged and still queries directly, since there is nothing to batch there. Three callers reach the batch path: the quality profile controller, download submission, and the six-hour automatic search sweep.

This is fewer queries as well as safer ones: a batch commonly spans many results across a handful of indexers, so it goes from one query per result to one per distinct indexer. IndexerSearchWorkflow already resolves its indexers before its own fan-out, so this brings the two in line.

Tested by counting the overlap directly rather than racing the EF exception: a stub IIndexerRepository records the highest number of calls it ever had in flight at once. It reports 12 without the change and 1 with it, over twelve results across three indexers, and pins the call count at 3 so a regression that restores per-result querying fails even if it happens not to overlap on a given run.

Change 2 (from #921): read Indexer.MinimumAge and Indexer.MaximumSize, and measure age in UTC

Fixes two of the three fields in #899, and leaves the third alone on purpose. Indexer.MinimumAge and Indexer.MaximumSize saved and reloaded and were read by nothing. Both are now applied in SearchResultScorer, beside Retention, which was already read there.

MaximumSize rejects a result larger than the indexer's own ceiling. It sits outside the existing size block, which is skipped for Usenet and reads QualityProfile.MaximumSize, a different setting with the same name. MinimumAge rejects a Usenet post that has not been up long enough, since grabbing too early tends to produce an incomplete or failed download; it does not apply to torrents, where a fresh post is complete.

Two things fell out of doing this. First, the indexer lookup moved above the size gate, since all three settings need it; that also fixes an ordering bug where a Usenet result recognized only by its indexer type was size-checked before the type correction that exempts it ran. Second, age was measured in the wrong timezone: the published date went through a bare DateTime.TryParse, which turns a trailing Z into the host's local time with Kind=Local, then got subtracted from DateTime.UtcNow. Every age was off by the server's UTC offset. It is parsed to UTC explicitly now, with AssumeUniversal for indexer dates carrying no offset.

SearchResultScorer.cs was at 498 lines against the architecture tests' 500-line cap, so the new UTC parse (TryParsePublishedDateUtc) and the title/profile detection helpers moved into SearchResultScorer.Helpers.cs and SearchResultScorer.PublishedDate.cs, both partials of the same class. No behavior changed in the move; the helpers moved unedited and the parse does exactly what the inline expression did.

Indexer.EnableRss is untouched. It advertises RSS sync, and there is no RSS sync anywhere in the codebase to enable; wiring it would mean building the feature, and removing it would presume the intent is to drop it. That is a question rather than a fix, raised separately.

Six tests added, each with an opposite case so none of them can pass against an implementation that always rejects. Reverting the UTC parse, the size gate, or the age gate each fails only its own test and leaves the rest green.

Change 3 (from #985): compute the profile size gates in long, not int

QualityProfile.MinimumSize and MaximumSize are int megabytes, and the scorer multiplied them by 1024 * 1024 in int arithmetic before comparing against a result's long byte size. At 2048 MB the multiply overflows int and wraps to a negative number, so the two gates fail in opposite directions: Maximum rejects every release, since everything is larger than a negative ceiling, and Minimum stops rejecting anything, since nothing is smaller than a negative floor. The settings form puts no upper bound on either field, and a 2 GB ceiling on an audiobook profile is ordinary.

The fix is the same (long) cast the indexer size gate a few lines above already uses, applied to both profile lines. Two tests added, each with a control row below the overflow threshold, so a change that simply stopped rejecting or simply started rejecting fails the control.

How the three fit together

All three touch SearchResultScorer.cs directly; #921 also touches its two partials, #863 also touches QualityProfileService.cs. The indexer-resolution change (#863) and the age/size/UTC change (#921) hit the same lines for different reasons, which is the conflict #921's original body flagged; #985's cast fix sits in the untouched profile size block a few lines below and does not interact with either. Nothing about combining them changes behavior beyond what each already documented on its own; there is no fourth interaction to call out.

Testing

Full backend suite run twice: on this PR's own branch before folding #863 and #985 in, and again after. Before: 3132 passed, 0 failed, 130 skipped. After: 3140 passed, 0 failed, 130 skipped. The 8 new passes are the concurrency test from #863 and the two overflow tests from #985; nothing else moved.

Disclosure: drafted with Claude Code at my direction; I read the cited code at the stated commit and reviewed this before posting.