Implemented and fixed many issues

Docs/StreamHub-API.md

@@ -120,8 +120,11 @@ Force a broadcast of the corresponding event.
 - `signal` — full key `src:sig`, or `src:sig[i]` to trigger on element *i* of a
   multi-element PACKET signal.
 - `edge` — `"rising"`, `"falling"` or `"both"`.
-- `windowSec` — total capture window (clamped to 1e-4 … 10 s).
-  `preSec = windowSec * prePercent / 100`, `postSec = windowSec − preSec`.
+- `windowSec` — total capture window. `preSec = windowSec * prePercent / 100`,
+  `postSec = windowSec − preSec`. Clamped to 1e-4 … 600 s by the Go hub and to
+  1e-4 … 60 s by the C++ one: the Go rings store min/max pairs once a window
+  outgrows their memory budget, so a long window costs resolution, while the C++
+  rings are fixed-capacity and would return the window truncated instead.
 - `mode` — `"normal"` (auto-rearm ~200 ms after capture) or `"single"`
   (stays TRIGGERED until `rearm`).
 
@@ -175,6 +178,33 @@ Every transition is broadcast as a `triggerState` event.
 Request the hub to send a `historyInfo` event (unicast). Also sent automatically
 on client connect.
 
+### `setHistoryBudget` (Go hub only)
+
+```json
+{"type":"setHistoryBudget","maxMPtsPerSignal":16.0}
+```
+Sets the per-signal archive budget in millions of stored points, the runtime
+equivalent of `-history-max-mpts`. `0` restores the 16 MPts default; the hub
+clamps to its own ceiling. Every archive file is re-created at the new size —
+**the archived samples are lost**, because a file's capacity and min/max bucket
+width are fixed at creation. Broadcasts `historyInfo` rather than answering the
+requester alone: every client's view of what history exists has been invalidated.
+
+### `setWindow` (Go hub only)
+
+```json
+{"type":"setWindow","seconds":60}
+```
+Reports how far back this client is plotting. The hub sizes its in-memory
+buffers for the **widest** window any connected client has reported (10 s if
+none has), bucketing each ring as min/max pairs when the window is too long to
+hold verbatim — see *In-memory buffer policy* in
+[StreamHub-Developer.md](StreamHub-Developer.md). While a trigger is armed the
+trigger's own window wins. No reply; send it on connect and whenever the
+timescale changes. A window the hub is not told about is a window whose start
+may already have rolled out of the ring, leaving a `zoom` over it nothing to
+answer with.
+
 ### `setMaxPoints`
 
 ```json
@@ -229,6 +259,20 @@ Sent at `StatsRate` Hz (default 1 Hz):
 `state` ∈ `idle | armed | collecting | triggered`; `trigTime` present once a
 trigger has fired.
 
+The Go hub adds `bufferFill` (0…1) and `bufferNeedSec` while `state` is `armed`
+**and** its buffers do not yet reach back far enough to deliver a whole window.
+Edges are ignored until they do, so that no capture arrives with a front that
+was never recorded; the fields are absent once the requirement is met.
+`bufferNeedSec` is how far back the hub must reach *now*, which is less than the
+window by however much its buffers will fill in on their own while the
+post-trigger window is collected: the pre-trigger span while they keep up with
+the stream, and up to the whole `windowSec` when they do not (a full ring
+re-bucketing for a longer window fills slower than real time, so the front of a
+capture recedes while it is being collected).
+The event is re-broadcast as the fraction grows, so a client can show the
+progress instead of an armed trigger that appears to be ignoring the signal.
+`forceTrigger` fires regardless.
+
 ### `zoom` (reply)
 
 ```json
@@ -243,18 +287,26 @@ trigger has fired.
 Sent on client connect (if history is enabled) and on `historyInfo` command:
 
 ```json
-{"type":"historyInfo","enabled":true,"durationHours":1.0,"decimation":10,
+{"type":"historyInfo","enabled":true,"windowSec":600.0,"decimation":10,
+ "maxMPtsPerSignal":16.777216,
  "signals":{
-   "scalar:Sine1":{"t0":1765360000.0,"t1":1765370000.0,"count":360000,"capacity":360000},
-   "scalar:Sine2":{"t0":1765360000.0,"t1":1765370000.0,"count":360000,"capacity":360000}}}
+   "scalar:Sine1":{"t0":1765360000.0,"t1":1765370000.0,"count":360000,"capacity":360000,"bucket":1},
+   "scalar:Sine2":{"t0":1765360000.0,"t1":1765370000.0,"count":360000,"capacity":360000,"bucket":1}}}
 ```
 - `enabled` — `true` if the `+History` config block is present and valid.
-- `durationHours` — configured history duration.
+- `windowSec` — the timespan the files are sized to hold, i.e. the live or
+  trigger window the clients are displaying (Go hub). The C++ StreamHub instead
+  keeps a fixed retention period and reports it as `durationHours`.
 - `decimation` — samples-to-disk decimation factor (1 = every sample).
+- `maxMPtsPerSignal` — current per-signal budget, in millions of stored points
+  (Go hub only; see `setHistoryBudget`).
 - `signals` — per-signal metadata keyed by `"sourceId:signalName"`:
   - `t0`/`t1` — oldest/newest timestamp stored on disk (Unix seconds).
   - `count` — number of valid entries currently in the circular file.
   - `capacity` — total capacity of the circular file.
+  - `bucket` — source samples per stored min/max pair (Go hub only); `1` means
+    the signal is archived verbatim, higher means it is stored as an envelope
+    because it is too fast to fit the budget at full resolution.
 
 ### `historyZoom` (reply)