fix(scoring): resolve indexers once per batch, not once per result in parallel

[m4bard]

Summary

ScoreSearchResults fans 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. This resolves each distinct indexer once before the fan-out and passes the results in.

Full write-up in #862.

Changes

Fixed

• QualityProfileService.ScoreSearchResults resolves the batch's distinct indexers sequentially up front and hands them to the scorer.
• SearchResultScorer takes an optional pre-resolved lookup and prefers it over querying.

The single-result ScoreSearchResult is unchanged and still queries; there is nothing to batch there, and it stays on the interface as it was.

Why it matters more than a caught exception suggests

The scorer already catches the failure and logs at Debug, so nothing fails. What it loses is indexerRetention, which stays 0, and the branch that sets isNzb from the indexer's type. Age and retention checks then score that result against assumptions that do not match its indexer. The batch comes back ordered plausibly and quietly wrong, and at the default log level there is nothing to see.

Three callers reach it: the quality profile controller, download submission, and the six-hour automatic search sweep.

Fewer queries, not just safer ones

A batch commonly carries many results across a handful of indexers. This goes from one query per result to one per distinct indexer, so it removes redundant work as well as the overlap.

IndexerSearchWorkflow already fetches its indexers before its own fan-out rather than inside it, so this makes the two agree rather than introducing an approach.

Testing

Asserting on the EF exception would mean racing it, which makes for a flaky test and a weak claim. The new test counts the overlap directly: a stub IIndexerRepository records the highest number of calls it ever had in flight at once, with a small delay so the overlap is observable rather than a scheduling accident.

It reports 12 concurrent without the change and 1 with it, over twelve results across three indexers. It also pins the call count at 3, one per distinct indexer, so a future change that restores per-result querying fails even if it somehow avoids overlapping.

Full suite: 3,030 passed, 0 failed, 125 skipped, against a 3,029 baseline on 03958c15.

Notes

The context's lifetime is the load-bearing fact here, so I verified it rather than inferring it from the registration. Reading the ServiceDescriptor back out of the built collection gives ListenArrDbContext => Scoped, with the repositories scoped as well. AddDbContextFactory(..., ServiceLifetime.Singleton) at PersistenceRegistrationExtensions.cs:25 registers the factory as a singleton and the context as scoped.

I have not reproduced wrong scores end to end against a running instance, and the issue says so. A collision needs the queries to actually overlap in time, which is machine-dependent. What is deterministic is that the calls are issued concurrently against a context that permits one at a time.