refactor(sessions): derive subscriber mode from session config; close Task 8 review nits

Remove the per-call allowMultipleSubscribers param from AttachEventSubscriber and
derive the mode internally from _eventStreaming.AllowMultipleEventSubscribers — the
same source SessionEventDistributor uses for singleSubscriberMode — so the two can
never structurally diverge. The maxSubscribers cap param is kept because
MaxEventSubscribersPerSession lives in SessionOptions, which the session does not hold
directly (only EventOptions flows through SessionEventStreaming).

Other nits:
- SubscriberCount XML doc clarifies it includes internal subscribers and differs from
  GatewaySession.ActiveEventSubscriberCount (external/gRPC only).
- SingleSubscriberMode_LoneExternalOverflow test: add Assert.Equal(1, observedSet) guard
  before the value assertion so the test cannot pass vacuously if the handler never fired.
- GatewayOptionsValidator.ValidateSessions: add explanatory code comment documenting why
  !AllowMultipleEventSubscribers && MaxEventSubscribersPerSession > 1 is NOT rejected as
  a hard error (the default config ships with this combination; the cap is simply unused
  in single-subscriber mode, not a behavior bug).
- GatewaySession.DetachEventSubscriber: add Debug.Assert before the clamp so a genuine
  double-decrement surfaces in debug builds.

src/ZB.MOM.WW.MxGateway.Server/Configuration/GatewayOptionsValidator.cs

@@ -181,6 +181,15 @@ public sealed class GatewayOptionsValidator : OptionsValidatorBase<GatewayOption
             options.MaxEventSubscribersPerSession,
             "MxGateway:Sessions:MaxEventSubscribersPerSession must be greater than zero.",
             builder);
+
+        // NOTE: We intentionally do NOT reject !AllowMultipleEventSubscribers &&
+        // MaxEventSubscribersPerSession > 1 as a hard validation error here. The default
+        // SessionOptions ships with AllowMultipleEventSubscribers=false and
+        // MaxEventSubscribersPerSession=8; making those defaults a validation failure would
+        // break every deployment that has not explicitly set the cap. The cap is simply
+        // ignored in single-subscriber mode (AttachEventSubscriber derives effectiveCap=1),
+        // so the only practical consequence of the apparent inconsistency is a dead config
+        // knob, not incorrect behavior.
     }
 
     private static void ValidateEvents(EventOptions options, ValidationBuilder builder)