refactor(bans): drop BanChannel.Configure, which only re-ran a swept Configure

BanConfiguration.Configure() is a static Configure() on a static class, so the
AssemblyHandler sweep already reaches it. BanChannel.Configure() did nothing but
call it -- and was itself swept AND called explicitly from NetState.Configure(),
so the same load was reached three ways.

Nothing reads BanConfiguration.Settings during the Configure phase (only the
accept path does, long after the sweep), so there was no ordering guarantee to
preserve here. Removed the method and the explicit call.

The equivalent-looking calls in BlocklistFilter.Configure() and
CrowdSecReporter.Configure() are NOT the same thing and stay: those are instance
methods the sweep never sees, invoked from Register(), and each reads its
settings immediately -- so calling their configuration loader first is a real
ordering guarantee, made free by the same idempotency guard.

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

Projects/Server/Network/NetState/NetState.cs

@@ -96,10 +96,6 @@ public partial class NetState : IComparable<NetState>, IValueLinkListNode<NetSta
 
         // Initialize IORingGroup and buffer pools
         ConfigureNetwork();
-
-        // Load ban policy. Reporters (content) register themselves during the same Configure sweep, as do
-        // the accept-path IConnectionFilters.
-        Bans.BanChannel.Configure();
     }
 
     // Internal constructor for accepted sockets