fix(download): search Soulseek more than once, and read file lengths

The slskd search asked one question and ignored part of the answer.

Two queries.  Soulseek matches every term against a file's full path,
so every extra word is a filter, and several filter wrongly: an edition
qualifier from the catalog title that no one puts in a folder name, a
term with a leading "-", which Soulseek reads as an exclusion, and
"Various Artists", which is in no one's path.  When a normalised form of
the request differs, it runs alongside the original and the candidates
are merged by peer and folder.  Concurrently, not as a fallback: the
manager gives a provider one search budget, and a Soulseek search spends
most of it waiting.  A query the user typed is searched as written.

Stated options.  The search carried only its id and text, so slskd's
own defaults for its timeout and response limits applied.  Its timeout
is now set inside our wait, the limits are well above a popular album,
and slskd drops folders below the file floor and peers with a queue we
would not reach today.

A state-only poll.  Every one-second poll re-sent every response; the
responses are now fetched once at the end, falling back to the old
includeResponses form for a daemon without that endpoint.

Durations.  slskd reports each file's length and it was discarded.  It
is now carried as CandidateFile.LengthMillis and scored against the
expected tracks as DurationFit, which takes 0.15 of title fit's weight
when at least half the aligned pairs are timed: a title says which song
a file claims to be, a length says whether it is that recording.
Without lengths the score is exactly the previous formula.

freeUploadSlots is removed from the response type; slskd sends
hasFreeUploadSlot and nothing by that name.

Closes #271

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017HJiuc3ZZhxsPXz3ozTirT

backend/download/types.go

@@ -232,12 +232,17 @@ type Candidate struct {
 // results give paths and sizes but no tags, so Format and duration are
 // inferred from the path and size where possible.
 type CandidateFile struct {
-	Path      string `json:"path"`
-	Size      int64  `json:"size"`
-	Format    Format `json:"format"`
-	Bitrate   int    `json:"bitrate,omitempty"` // kbps, 0 when unknown
-	IsAudio   bool   `json:"isAudio"`
-	MatchedTo int    `json:"matchedTo,omitempty"` // expected track position
+	Path    string `json:"path"`
+	Size    int64  `json:"size"`
+	Format  Format `json:"format"`
+	Bitrate int    `json:"bitrate,omitempty"` // kbps, 0 when unknown
+	IsAudio bool   `json:"isAudio"`
+
+	// LengthMillis is the file's duration as the source reports it, or
+	// 0 when it does not.  Soulseek reports it for most audio files.
+	LengthMillis int64 `json:"lengthMillis,omitempty"`
+
+	MatchedTo int `json:"matchedTo,omitempty"` // expected track position
 }
 
 // Format is a normalized audio container/codec name.
@@ -286,7 +291,14 @@ type MatchScore struct {
 	TitleFit     float64 `json:"titleFit"`     // filenames vs expected titles
 	ArtistFit    float64 `json:"artistFit"`    // path/origin vs expected artist
 	AlbumFit     float64 `json:"albumFit"`     // folder name vs album title
-	Completeness float64 `json:"completeness"` // audio files vs expected count
+	Completeness float64 `json:"completeness"` // aligned tracks vs expected count
+
+	// DurationFit is how well the aligned files' lengths agree with the
+	// expected tracks', and DurationKnown whether enough of them stated
+	// a length for that to count.  When it does not, the score is the
+	// four text signals alone, exactly as before durations were read.
+	DurationFit   float64 `json:"durationFit"`
+	DurationKnown bool    `json:"durationKnown"`
 
 	// Anchored records whether an MBID drove this score.  Unanchored
 	// matches are capped, because there is nothing to be right about.