refactor(download): rename Want/Request to Request/Download, unify downloads flow, add auto-download guardrails

The durable "I asked for this" record was called Want, and the one-shot
search-and-grab attempt was called Request — names that didn't match
what either actually did. Want is now Request, and the old Request/Item
is now Download/DownloadItem, with a table-rename migration
(download_wants -> download_requests, old download_requests ->
download_downloads) safe against both fresh installs and existing data.

Every anchored manual download now upserts/reuses a durable Request
before running, so a "download now" that finds nothing is picked up by
the background reconciler automatically instead of just failing with
no trace — the gap that caused this session's repeated "no candidates
found" failures on the same album.

Also adds auto-download guardrails (file-size min/max with a preferred
target, allowed file types) that gate what the pipeline may grab
unattended, live-editable from a new settings section. The frontend's
wanted-view becomes downloads-view, with a new Downloads tab showing
attempt/transfer history that previously had no UI at all.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y2Agd9af5hE7qzti2ackiS

backend/events/events.go

@@ -123,15 +123,15 @@ const (
 	// open download picker re-read the provider list.
 	DownloadProvidersChanged = "DownloadProvidersChanged"
 
-	// DownloadsChanged fires when the set of download requests changes
-	// (started, picked, cancelled, cleared).  Per-transfer progress does
-	// not use this — it flows through the jobs registry's JobsChanged,
-	// which already coalesces high-frequency updates.
+	// DownloadsChanged fires when the set of downloads changes (started,
+	// picked, cancelled, cleared).  Per-transfer progress does not use
+	// this — it flows through the jobs registry's JobsChanged, which
+	// already coalesces high-frequency updates.
 	DownloadsChanged = "DownloadsChanged"
 
-	// WantedListChanged fires when the wanted list gains, loses or
+	// RequestsChanged fires when the request list gains, loses or
 	// retires an entry — including from a background reconcile pass,
 	// which is why the list is event-driven rather than fetched once on
 	// mount.
-	WantedListChanged = "WantedListChanged"
+	RequestsChanged = "RequestsChanged"
 )