fix(downloads): make import quality comparison profile-aware (#582)

[jaredvincent414]

Summary

When a completed download is imported for an audiobook that already has files, Listenarr is supposed to consult the audiobook's quality profile and skip the incoming file when it isn't an upgrade. That decision ran through ImportQualityEvaluator.IsAcceptable, which accepted a QualityProfile but never read it — it compared a regex-extracted numeric bitrate instead:

return !TryParseBitrate(candidate, out var c) || !TryParseBitrate(existing, out var e) || c >= e;

Any non-numeric quality (an existing FLAC) fails that parse and falls through to "acceptable", so a lossy MP3 gets imported on top of a lossless file and the audiobook ends up with both.

A profile-aware, lossless-aware comparator already exists in the domain — QualityMatcher — and the automatic-search path already uses it. Import was the only path still on the old regex evaluator. This PR routes import onto it.

Fixes #582. Related: #549 (quality determination algorithm).

Changes

Added

• QualityMatcher.IsLossless(AudioQualityInput) — public wrapper over the existing private lossless check, so callers outside the profile path can still honour lossless-vs-lossy.
• ImportQualityEvaluator.FromFile(...) / FromMetadata(...) — project an AudiobookFile and an incoming download's AudioMetadata into the shared AudioQualityInput vocabulary.
• ImportQualityEvaluator.Describe(...) — readable quality label for the import skip log.
• Four quality-gating tests: numeric upgrade, cross-codec (lossless-over-lossy) upgrade, equal-quality reimport, and unknown-quality/no-profile.

Changed

• ImportQualityEvaluator.IsAcceptable now takes AudioQualityInput and ranks both sides through the profile's rung priority. When there is no profile, an empty profile, or a side the profile cannot rank, it falls back to codec/bitrate facts — lossy never lands on top of lossless, and genuinely unknown quality still imports rather than being silently dropped.
• DownloadImportService picks the hardest-to-beat existing file via the same comparator, and gates the candidate through it.

Fixed

• A lossy download no longer imports over an existing lossless file (Quality filters: Flaws in the current logic #582).
• The "best existing quality" loop no longer hardcodes MP3 bitrate buckets ("MP3 320kbps" etc.), which mislabelled every non-MP3 file as MP3.

Removed

• The regex TryParseBitrate decision helper.

Testing

• dotnet test — 1020 passed, 0 failed.
• cd fe && npm run test:unit — 389 passed; npm run type-check clean.
• dotnet build — 0 warnings, 0 errors. Pre-commit (format, layering, async void) and pre-push (format, type-check, FE tests) hooks pass.

The reproduction is QualityGating_LosslessExisting_SkipsLossyDownload: an audiobook with an existing FLAC and a profile ranking FLAC above MP3 receives a lossy MP3 download. Before this change the MP3 was imported and the audiobook held two files; now it is skipped.

Worth being straight about the other four tests: they would also pass against the old code (its regex fell through to "acceptable" for any non-numeric label, so it imported in all four cases). They exist to guard against over-correction, not to prove the fix. The load-bearing one is QualityGating_EqualQuality_IsImported — it fails if the gate is ever tightened to the strictly-better rule search uses, which would skip every part of a multi-file audiobook whose quality merely matches what is already on disk.

Notes

Import compares "not worse"; search compares "strictly better". That asymmetry is deliberate and now documented in the code. Import must accept equal quality, or multi-file audiobooks would have every part skipped.

The delete/replace half of #582 is deliberately not here. The issue also proposes removing existing files when the incoming quality is better. That is a separate, riskier change and — per @Paelsmoessan's comment on the issue — is blocked on #542 (multi-file size aggregation), #736 (recycling bin, so a wrong quality call is not data loss), and #737 (imported files have no stored codec/bitrate). Deferring it keeps this PR to one bug fix.

Behaviour change for users with no quality profile. The fallback means lossy-over-lossless is now blocked even when no profile is configured. This is intended — previously nothing gated those users — but it is a real behaviour change worth flagging.