Downloads: make the simultaneous-download limit a user setting #404

1.8.0 (the downloads overhaul) introduced fixed admission caps in DownloadAdmissionPolicy. Rows beyond them show "Waiting for a download slot…" until a slot frees:

These were a safety-first starting point to stop relaunch recovery restarting everything at once (the build-1506/1513 field reports). They were not tuned for throughput. The best value depends on things the app can't infer:

• server upload bandwidth and disk;
• whether the server is on the LAN or a remote path;
• device storage speed;
• how many transcodes the server can handle.

Proposal

• Add one setting, "Simultaneous downloads": 1–5, default 3.
• Derive the static-file lane from it (total − 1, minimum 1).
• Keep server preparation at 1 and live forward at 1. Those are server-load limits, not device ones.
• Lowering the value never cancels running transfers. Rows that are already running are grandfathered, as P4 already does over the cap.
• Raising it admits waiting rows on the next pass.
• Relaunch recovery keeps honouring the setting, so recovery fan-out stays bounded.
• Put it in Settings ▸ Downloads next to the network toggle (D5), on visionOS, iOS/iPadOS and macOS. tvOS has no downloads.

Tests

• Admission policy unit tests across the range.
• Lowering the cap mid-transfer: no cancellation, and no new admits until occupancy drops.
• The relaunch cap applies the stored setting.

Not a blocker for landing the overhaul (#403).