feat(comm): batch site→central stream events over gRPC (R2)

Every AttributeValueChanged/AlarmStateChanged rode its own gRPC message on
SiteStreamService; at target scale that is ~37.5k messages/s/site of pure
framing overhead. Coalesce them, additively, with no new RPC.

Wire (sitestream.proto, regenerated via docker/regen-proto.sh sitestream):
  InstanceStreamRequest.batching_supported = 3
  SiteStreamRequest.batching_supported     = 2
  SiteStreamEvent.batch                    = 4  (new oneof case)
  SiteStreamEventBatch { repeated SiteStreamEvent events = 1 }

The proto3 default of batching_supported IS the negotiation, and it is
load-bearing: a batch frame reaches a pre-R2 central as EventOneofCase.None,
whose ConvertToDomainEvent returns null — the whole batch would vanish with
no error anywhere. An old central cannot set the flag so it never receives
one; an old site ignores the unknown request field and keeps sending
per-event frames, which the new client's ForEachEvent handles as the
single-event case. Both skew directions are covered by tests that go through
a real proto serialize/parse round-trip.

Server: SiteStreamEventBatcher, a per-subscriber pump replacing the handler's
await-foreach/WriteAsync loop and byte-identical to it at a cap of 1. It
never delays a lone event — it drains the already-queued backlog for free and
lingers only once a backlog is proven — emits a single-event buffer as a
plain frame, preserves order and per-event Timestamps exactly, and flushes
what is buffered when the send channel's writer completes. It sits DOWNSTREAM
of StreamRelayActor's bounded DropOldest channel, so it changes framing only
and does not move the burst ceiling (deferred register row 31, which lives in
the shared publish stage upstream of the BroadcastHub).

Client: sets the flag on both subscriptions and unpacks in order into the
existing per-event pipeline, so SiteAlarmAggregatorActor,
DebugStreamBridgeActor, consumer-keepalive/orphan logic,
reconnect-on-graceful-completion, generation fencing, the (siteId, endpoint)
factory key and IsLive semantics are untouched.

Options (validated): GrpcStreamBatchMaxEvents 100 (1 disables),
GrpcStreamBatchWindow 25 ms — validated strictly under 250 ms, the load
test's end-to-end P99 threshold. Measured worst case (trickle-with-backlog,
window-bound rather than cap-bound): P50 13.8 ms, P99 25.4 ms, max 25.8 ms;
cap-bound case sent 600 queued events in 6 frames.

Telemetry: histogram scadabridge.site.stream.batch_size tagged by stream
kind, recorded only on negotiated streams (per-event otherwise). It rides
ScadaBridgeTelemetry.MeterName, already in the ObservedMeters allowlist.

Docs: Component-Communication.md gains an Event Batching section; CLAUDE.md's
gRPC streaming bullet records the wire shape and the negotiation rationale.

src/ZB.MOM.WW.ScadaBridge.Communication/CommunicationOptionsValidator.cs

@@ -12,6 +12,14 @@ namespace ZB.MOM.WW.ScadaBridge.Communication;
 /// </summary>
 public sealed class CommunicationOptionsValidator : OptionsValidatorBase<CommunicationOptions>
 {
+    /// <summary>
+    /// Exclusive upper bound on <see cref="CommunicationOptions.GrpcStreamBatchWindow"/> —
+    /// the end-to-end site→central event latency budget the target-scale load test asserts
+    /// a P99 against. The coalescing window is the only latency batching introduces, so it
+    /// must stay strictly inside that budget rather than consuming it whole.
+    /// </summary>
+    internal static readonly TimeSpan StreamBatchWindowCeiling = TimeSpan.FromMilliseconds(250);
+
     /// <inheritdoc />
     protected override void Validate(ValidationBuilder builder, CommunicationOptions options)
     {
@@ -75,6 +83,23 @@ public sealed class CommunicationOptionsValidator : OptionsValidatorBase<Communi
         builder.RequireThat(options.GrpcMaxConcurrentStreams > 0,
             $"ScadaBridge:Communication:GrpcMaxConcurrentStreams must be positive (was {options.GrpcMaxConcurrentStreams}).");
 
+        // ── Site→central stream event batching (R2) ─────────────────────────────
+        // 1 is legal and means "disabled" (one event per frame, the un-negotiated shape).
+        builder.RequireThat(options.GrpcStreamBatchMaxEvents > 0,
+            $"ScadaBridge:Communication:GrpcStreamBatchMaxEvents must be positive — 1 disables "
+            + $"batching (was {options.GrpcStreamBatchMaxEvents}).");
+
+        // The coalescing window is the ONLY latency batching can add, and the target-scale
+        // load test holds end-to-end event latency to a 250 ms P99. Validate it strictly
+        // below that so a misconfigured window cannot silently spend the entire budget.
+        builder.RequireThat(
+            options.GrpcStreamBatchWindow >= TimeSpan.Zero
+            && options.GrpcStreamBatchWindow < StreamBatchWindowCeiling,
+            $"ScadaBridge:Communication:GrpcStreamBatchWindow must be non-negative and strictly "
+            + $"below {StreamBatchWindowCeiling.TotalMilliseconds:0} ms (the end-to-end stream "
+            + $"latency budget the coalescing window spends from); zero means \"pack only what is "
+            + $"already queued\" (was {options.GrpcStreamBatchWindow}).");
+
         // The gRPC site→central transport needs at least one central endpoint to dial. gRPC is now
         // the only site→central transport (ClusterClient was removed in the migration's Phase 4), so
         // every site node must declare its central endpoints — there is no Akka fallback to ignore