fix(quality): let a real encoder bitrate reach the rung it was encoded for

[m4bard]

Fixes one of the causes behind #549, where books report quality-mismatch against a profile they
should satisfy.

What happens

QualityMatcher.NormalizeKbps rounds a reported bitrate to whole kbps, and rung eligibility was

withBitrate.Where(r => r.BitrateKbps <= kbps)

A file encoded at a nominal 128kbps does not report 128000 bps. It reports something like 127241,
which rounds to 127, so the 128 rung is excluded and the file falls to the tier below. Where that
lower tier sits under the profile cutoff, the book reports a mismatch.

Most lossy files land at least a little under their nominal tier, so this is not an occasional
rounding artifact. It is closer to the normal case.

The change

Eligibility goes through MeetsRung, which lets a file reach a rung it falls just short of. The
tolerance is five percent, with a floor of one kbps.

Adjacent rungs in an ordinary profile sit much further apart than that. 64, 96, 128, 192, 256 and 320
are at least a third apart, so the tolerance cannot carry a file across a real tier boundary. There
is a test for exactly that: a 96kbps file against a profile of 128 and 64 still matches 64.

Tests

Two, both failing before the change. One at QualityMatcher, one at AudiobookStatusEvaluator so
the user-visible status is covered and not just the internals.

It is worth saying why the existing tests did not catch this. Every bitrate in QualityMatcherTests
and AudiobookStatusEvaluatorTests is an exactly round tier value: 256000, 320000, 128. The suite
only ever asks the question in the one form where the answer was already right.

Scope, and what this does not fix

This is one cause. It is not the whole of #549.

Measured on a real library before and after, the share of books with a file reporting
quality-mismatch went from roughly nine in ten to roughly two in three. Better, and obviously not
finished.

The rest looks like a different mechanism, which I have left alone here.
AudiobookStatusEvaluator.ComputeStatus filters the file list by the profile's PreferredFormats
before the matcher is consulted, and a book left with no candidate files returns QualityMismatch.
So a book whose only files are in a format the profile does not prefer reports a quality mismatch
whatever its bitrate:

mp3 at 320000 bps, PreferredFormats ["m4b"]  ->  quality-mismatch
mp3 at 320000 bps, PreferredFormats []       ->  quality-match

On that library, every book that matched was AAC and every MP3-only book was mismatched regardless
of bitrate, against an m4b-only PreferredFormats.

I do not think that is mine to decide. There is a reading where a book in a format you did not ask
for is legitimately not what you wanted. But quality-mismatch is the status the UI reads, so
treating a format preference as a quality shortfall reaches further than the label does, and
redefining that status does not belong in a pull request about rounding. I can open a separate issue
for it if that is useful.

---

Worked through with Claude Code at my direction. The mechanism and both tests were checked by
running them, including confirming they fail without the change. The before and after rates come
from a real library rather than from the test suite. I reviewed this before posting.