fix(search): read Indexer.MinimumAge and Indexer.MaximumSize, and measure age in UTC

[m4bard]

Fixes two of the three fields in #899, and leaves the third alone on purpose.

Indexer.MinimumAge and Indexer.MaximumSize save and reload 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. That is a different setting with the same name, which is worth saying out loud: grepping for MaximumSize finds the profile one and makes the indexer field look wired.

MinimumAge rejects a Usenet post that has not been up long enough. The reason is propagation rather than preference, since grabbing too early produces an incomplete or failed download. It does not apply to torrents, where a fresh post is complete.

Two things fell out of doing this

The indexer lookup had to move above the size gate, because all three settings need it. That also fixes an ordering bug: the lookup is what corrects isNzb from the indexer's own type, and it used to run after the size gate, so a Usenet result recognised only by its indexer type was size-checked despite the exemption immediately below it.

Age was measured in the wrong timezone. The published date went through a bare DateTime.TryParse, which converts a trailing Z to the host's local time and returns Kind=Local, and the result was then subtracted from DateTime.UtcNow. Every age was out by the server's UTC offset, so results looked older west of UTC and newer east of it. At day granularity that usually only matters at a boundary. At the minute granularity MinimumAge needs, it decides the answer, which is how I noticed: a post ten minutes old measured as five hours old on a UTC-5 host.

It is parsed to UTC explicitly now, with AssumeUniversal for indexer dates that carry no offset. The test for it uses a timestamp written with a +09:00 offset, so it does not depend on where it runs.

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; removing it would presume you do not intend to. That one is a question rather than a fix and I would rather ask it separately.

An expected conflict

This conflicts with my own #863 in SearchResultScorer.cs, which changes how the indexer is obtained so a batch resolves it once. Same lines, different concerns. Whichever of the two lands first, I will rebase the other. I tried stacking this on #863 instead and it dragged five commits already in canary into the diff, so a plain note seemed better than a confusing PR.

Tests

Six added, each with its 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 its own test and leaves the others green.

---

Worked through with Claude Code at my direction. The claims above were checked by running them rather than by reading, and I reviewed this before posting.