v0.19.0 — Bump default parallel segments 8→16 to shorten end-of-DL tail

Issue : on a 14 GB download with 8 segments, when 7 finish there's only
1 connection left handling its assigned 1.75 GB → apparent throughput
collapses to 1/8th of the peak for the final stretch (~5 min visible
slowdown at the end).

Quick fix : double the default segment count.
- 8 segments  : last has 1.75 GB to finish alone
- 16 segments : last has 875 MB → tail ~halved

Tuning surfaced in Settings → Avancés → Serveur as
« Connexions parallèles pour les téléchargements (1-32, défaut 16) ».
Power users on faster servers can push to 24-32. OVH mutualisé tolerates
up to 16-24 ; above that, soft rate-limiting kicks in.

Aligned :
- LocalConfig default : 8 → 16
- DownloadManager clamp : Math.Clamp(_, 1, 16) → 1, 32
- HttpClient handler MaxConnectionsPerServer : 16 → 32 (matches new ceiling)

Versions bumped to 0.19.0.

Existing config.json files will keep their previous value (8) untouched ;
delete config.json to pick up the new default, or just bump it in
Settings → Avancés.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/PSLauncher.Core/Downloads/DownloadManager.cs

@@ -176,7 +176,10 @@ public sealed class DownloadManager : IDownloadManager
         }
 
         // 2. Choix single vs multi-segment
-        var requestedSegments = Math.Clamp(_config.ParallelDownloadSegments, 1, 16);
+        // Hard-cap à 32 : au-delà OVH mutualisé risque le rate-limit per-IP et le
+        // gain marginal devient négatif. 16 = défaut, 24-32 OK pour les serveurs
+        // qui le supportent. 1 = comportement single-segment legacy.
+        var requestedSegments = Math.Clamp(_config.ParallelDownloadSegments, 1, 32);
         var useMultiSegment = requestedSegments > 1
             && job.ExpectedSize >= MultiSegmentMinSize
             && (existing is null || existing.Segments.Count > 0);