Correct the reasoning behind the attempt backoff

baa936e claimed muse's enqueue burst stalled slskd and took other users'
searches down with it. That is not what happened, and the log says so plainly:
"Failed to resolve search response" timeouts run at 10-178 per hour, every
hour, for as long as the log is retained -- they are constant background from
slskd answering other people's searches over a network full of unreachable
peers. Seeing three of them in the same minute as five of muse's own enqueue
timeouts was a coincidence I read as causation.

What is actually true is narrower: an unreachable peer is common, slskd reports
it as a 500, and the ladder exists to walk past it. The backoff stands as
ordinary politeness rather than a fix, and the README now says that instead of
claiming a harm that was never measured.

No behaviour change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -258,19 +258,22 @@ A download that sits with no bytes for `MUSE_STALL_MINUTES` is abandoned the
 same way, as is one slskd has forgotten about. Both used to leave the job in
 `downloading` forever, with a cheerful pulsing dot and no log line.
 
-**Not every failure is about the file.** "File not shared" concerns one file and
-the next candidate is unaffected, so the ladder advances immediately. A timeout
-says only that slskd could not talk to anyone just then, and the next candidate
-would fail identically. Walking the whole list to learn that once is waste --
-worse, it is harmful: each enqueue blocks about five seconds on a peer
-connection, so eight back-to-back attempts is forty seconds of pressure on one
-subsystem, and it takes other users' searches down with it. That is not
-hypothetical; it is what a real request did.
+**Unreachable peers are the norm, not the exception.** slskd answers 500 when it
+cannot open a connection to a peer within its five-second window, and on a live
+instance that is common: one request walked four such peers before the fifth
+served it. This is why the ladder is worth having and why `MUSE_MAX_ATTEMPTS`
+defaults to the full `MUSE_CANDIDATES` rather than a smaller number — a cap
+below the ladder size throws away candidates that would have worked.
 
-So attempts are spaced by `MUSE_ATTEMPT_BACKOFF`, and after
-`MUSE_SYSTEMIC_LIMIT` consecutive connection failures muse stops and **keeps the
-untried candidates on the row**. Retrying then resumes the ladder where it
-stopped rather than paying for a search whose answer has not changed.
+Attempts are spaced by `MUSE_ATTEMPT_BACKOFF`. That is politeness rather than a
+fix for anything measured: each enqueue holds a peer connection slot for up to
+five seconds, and there is no reason to ask for eight of them in immediate
+succession. Separately, `MUSE_SYSTEMIC_LIMIT` consecutive *connection* errors —
+meaning slskd itself is unreachable, not a peer — stop the walk and **keep the
+untried candidates on the row**, so retrying resumes the ladder rather than
+paying for a search whose answer has not changed. A 500 is deliberately not
+counted as systemic: it describes one peer, and treating it as systemic would
+have abandoned the request that succeeded on its fifth attempt.
 
 ## Review: when muse isn't sure