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.App/PSLauncher.App.csproj

@@ -15,9 +15,9 @@
     <Product>PROSERVE Launcher</Product>
     <Copyright>© 2026 ASTERION VR — All rights reserved</Copyright>
     <RootNamespace>PSLauncher.App</RootNamespace>
-    <Version>0.18.0</Version>
-    <AssemblyVersion>0.18.0.0</AssemblyVersion>
-    <FileVersion>0.18.0.0</FileVersion>
+    <Version>0.19.0</Version>
+    <AssemblyVersion>0.19.0.0</AssemblyVersion>
+    <FileVersion>0.19.0.0</FileVersion>
 
     <!-- Single-file self-contained publish profile (used by `dotnet publish`) -->
     <PublishSingleFile>true</PublishSingleFile>