chore(historian): batch-era defaults + appsettings/doc alignment

src/Server/ZB.MOM.WW.OtOpcUa.Runtime/Historian/ContinuousHistorizationOptions.cs

@@ -43,6 +43,15 @@ public sealed class ContinuousHistorizationOptions
     ///     every <see cref="CommitIntervalMs"/> ms (higher throughput, a bounded worst-case loss window).
     ///     Parsed case-insensitively against <c>HistorizationCommitMode</c>; an unrecognized value falls
     ///     back to <c>PerEntry</c>.
+    ///     <para>
+    ///         <b><c>PerEntry</c> now means one fsync per ingest <em>burst</em>, not per value.</b> The
+    ///         recorder appends a whole value burst through
+    ///         <c>IHistorizationOutbox.AppendBatchAsync</c>, which enqueues every entry and then issues a
+    ///         <em>single</em> group commit — so a burst of N values costs one fsync instead of N. The
+    ///         durability contract is unchanged: <c>AppendBatchAsync</c> does not return until that
+    ///         commit completes, so nothing the caller has been told is buffered can be lost to an
+    ///         unclean restart.
+    ///     </para>
     /// </summary>
     public string CommitMode { get; init; } = "PerEntry";
 
@@ -50,9 +59,23 @@ public sealed class ContinuousHistorizationOptions
     /// <see cref="CommitMode"/> is <c>Periodic</c>. Ignored under <c>PerEntry</c>.</summary>
     public int CommitIntervalMs { get; init; } = 100;
 
-    /// <summary>Maximum outbox entries peeked + written per drain pass; clamped to a positive value by
-    /// the recorder (a non-positive value falls back to 64).</summary>
-    public int DrainBatchSize { get; init; } = 64;
+    /// <summary>
+    ///     Maximum outbox entries peeked + written per drain pass; clamped to a positive value by the
+    ///     recorder (a non-positive value falls back to the default).
+    ///     <para>
+    ///         Defaults to 1024. It was 64 when a pass wrote its per-tag groups <em>sequentially</em>, so
+    ///         a wide batch cost <c>tags × latency</c> on the drain thread. Both halves of that reasoning
+    ///         are gone: the peek is an in-memory scan of the outbox's live index (widening it costs
+    ///         allocation, not I/O), and the pass is now bounded-parallel over
+    ///         <see cref="DrainConcurrency"/>, so its cost is <c>⌈tags / concurrency⌉ × latency</c>
+    ///         regardless of batch width. At 64, a drain draws down at most 64 entries every
+    ///         <see cref="DrainIntervalSeconds"/> — below the arrival rate of even a modest historized
+    ///         tag set — so any gateway hiccup left the outbox permanently behind, growing toward
+    ///         <see cref="Capacity"/> and shedding oldest samples, rather than catching up once the
+    ///         gateway recovered.
+    ///     </para>
+    /// </summary>
+    public int DrainBatchSize { get; init; } = 1024;
 
     /// <summary>Steady drain cadence in seconds (also the post-success reschedule). Defaults to 2.</summary>
     public double DrainIntervalSeconds { get; init; } = 2;