Try the whole ladder, rather than five eighths of it

MAX_ATTEMPTS was 5 while CANDIDATES was 8, so three ranked candidates were
gathered and then never tried. The cap was arbitrary and the live numbers show
what it cost.

slskd answers 500 whenever it cannot open a connection to a peer, and that is
common: retrying "Michael Jackson - Billie Jean" walked four unreachable peers
before the fifth served it -- succeeding on precisely the last attempt the cap
allowed. "The Weeknd - Die For You" ran the same gauntlet and lost, giving up
with three untried candidates still on the row.

Defaults to CANDIDATES, so the ladder is the ladder. Anyone wanting the old
behaviour can still set MUSE_MAX_ATTEMPTS.

The cap test lowers the value explicitly now; with the two equal by default it
was only ever proving the list ran out, which is the other branch.

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

app.py

@@ -80,7 +80,14 @@ TITLE_FLOOR = float(os.getenv("MUSE_TITLE_FLOOR", "0.5"))
 # one is tried instead of failing the request -- "File not shared." is a
 # per-file condition, so candidate two usually just works.
 CANDIDATES = int(os.getenv("MUSE_CANDIDATES", "8"))
-MAX_ATTEMPTS = int(os.getenv("MUSE_MAX_ATTEMPTS", "5"))
+
+# Defaults to the size of the ladder, because keeping eight candidates and then
+# refusing to try three of them is a cap with no reasoning behind it. Measured
+# on a live instance: slskd answers 500 whenever it cannot open a connection to
+# a peer, which is common enough that requests routinely need four or five
+# attempts. One succeeded on exactly the fifth; another gave up at the cap with
+# three candidates still in hand.
+MAX_ATTEMPTS = int(os.getenv("MUSE_MAX_ATTEMPTS", str(CANDIDATES)))
 
 # A download that has moved no bytes for this long is not going to. The peer
 # queued it and vanished, or slskd lost the transfer; either way the job used