Add a proxy pool with rotation, liveness checks and a management page

The parser will need to move between proxies, so this adds the module it will
sit on: pluggable sources, a pool that hands proxies out and learns from the
outcome, three rotation strategies, and a page to drive it.

Sources are IProxySource implementations. The public proxifly/free-proxy-list
feed is fetched as the combined all/data.json through jsDelivr and filtered
locally — one conditional request beats four per-protocol ones that can disagree
mid-publish — and cached for the five minutes upstream takes to regenerate. A
feed that is down keeps serving its last payload rather than emptying the pool.
The user's own list lives in proxies.custom.json beside the settings, takes a
pasted blob, and names the lines it could not parse instead of quietly dropping
them.

Both knobs the pool exposes are settings, as asked: rotation is Sticky (default,
the only one that keeps site sessions coherent), RoundRobin or WeightedRandom;
liveness is either a parallel sweep of the whole pool or a probe at hand-out
time. Free lists are a few percent alive, so skipping verification entirely
means mostly waiting on timeouts.

Two invariants worth keeping, both of which cost a bug to find:

Availability is decided by the quarantine, never by Health. Excluding everything
that has ever failed made the quarantine window dead code and discarded proxies
permanently on their first hiccup, which is exactly wrong for addresses that
flap constantly. Health only orders the candidates now.

A probe verdict does not touch the success/failure counters. Those are about
real requests, and letting a sweep over a few thousand proxies rewrite them
would drown the evidence weighted selection reads.

SOCKS needs no extra package — .NET resolves socks4/socks4a/socks5 in WebProxy —
but a proxifly record with "protocol": "https" is still an HTTP proxy reached
over http:// with CONNECT, not an https:// scheme.

115 new tests. Also fixes a pre-existing flake: a command gated on another
command's IsExecuting cannot be driven straight after its Execute() completes,
because IsExecuting is published on the output scheduler.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/AvParser.UI/DependencyInjection/UiServiceCollectionExtensions.cs

@@ -1,4 +1,5 @@
 using AvParser.Core.Parsing;
+using AvParser.Core.Proxies;
 using AvParser.Core.Settings;
 using AvParser.Infrastructure.Storage;
 using AvParser.UI.Navigation;
@@ -37,13 +38,20 @@ public static class UiServiceCollectionExtensions
             sp.GetRequiredService<ISettingsService>(),
             sp.GetRequiredService<IThemeService>(),
             sp.GetRequiredService<IAppPaths>(),
-            sp.GetRequiredService<LoggingLevelSwitch>()
+            sp.GetRequiredService<LoggingLevelSwitch>(),
+            sp.GetRequiredService<IProxyPool>()
+        ));
+        services.AddSingleton<ProxiesViewModel>(static sp => new ProxiesViewModel(
+            sp.GetRequiredService<IProxyPool>(),
+            sp.GetRequiredService<IMutableProxySource>(),
+            sp.GetRequiredService<ILogger<ProxiesViewModel>>()
         ));
         services.AddSingleton<AboutViewModel>();
 
         // Order here is the order of the navigation rail; the first entry is the landing page.
         services.AddSingleton<PageViewModel>(static sp => sp.GetRequiredService<DashboardViewModel>());
         services.AddSingleton<PageViewModel>(static sp => sp.GetRequiredService<ParseViewModel>());
+        services.AddSingleton<PageViewModel>(static sp => sp.GetRequiredService<ProxiesViewModel>());
         services.AddSingleton<PageViewModel>(static sp => sp.GetRequiredService<SettingsViewModel>());
         services.AddSingleton<PageViewModel>(static sp => sp.GetRequiredService<AboutViewModel>());