fix(historian): #689 size reverse-walk segments from the page, not the tie budget

ReverseRawReader aimed every segment at half of MaxTieClusterOverfetch
(~32k rows by default) and carried that width page to page, so a paged
'latest N' read on a dense Gateway tag fetched ~32,770 rows per page
(2-5 s live) to return N. The walk now lives in a generic ReverseWalk
core: segments are aimed at ~N+8 rows (page budget 2N+16), a discovery
segment (first without a hint / after an empty one) may read 1,024, and
the tie budget is only the ceiling a single-timestamp cluster escalates
to. A truncated read never re-enters the stretch below its newest row
until the gap above it is bisected. Tests: per-page row counts on a
dense tag (node manager + walk), randomized exactness fuzz (walk and
node-manager paging), dense-tag-below-a-long-gap read bound.

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

@@ -82,8 +82,8 @@ public sealed class ServerHistorianOptions
     ///     <c>MaxTieClusterOverfetch + 1</c> ties at that single timestamp (a <c>start == end</c> read) and
     ///     pages through them; this bounds how large a single-timestamp burst the server will buffer in
     ///     memory before it gives up and surfaces <c>BadTooManyOperations</c> for that node (#686; was
-    ///     <c>BadHistoryOperationUnsupported</c>). It is also the per-read row budget of a reverse raw read walked
-    ///     back from forward reads on a backend that cannot read newest-first (the Gateway): one timestamp holding
+    ///     <c>BadHistoryOperationUnsupported</c>). It is also the tie-cluster CEILING of a reverse read walked
+    ///     back from forward reads on a backend that cannot read newest-first (the Gateway; segments are sized from the page, #689): one timestamp holding
     ///     more samples than this is refused <c>BadTooManyOperations</c>. The default (65536) comfortably covers
     ///     any realistic same-millisecond burst; a value below 1 is treated as 1.
     /// </summary>