fix(alarms): fetch/poll ceilings; truncation-semantics docs; log-format conformance

docs/AlarmClientDiscovery.md

@@ -140,6 +140,26 @@ Two viable A.2 designs given the probe data:
    poll period; modest CPU floor because the call is cheap. Matches
    the heartbeat-style WM 0xC275 semantics — AVEVA itself runs a
    poll loop internally.
+
+   As shipped, this is the chosen design, and the cadence is **no
+   longer fixed at 500 ms**: it is the 500 ms *default* of
+   `MxGateway:Alarms:PollIntervalMilliseconds` (range 100 ms – 1 h),
+   which the gateway hands the worker through the
+   `MXGATEWAY_ALARM_POLL_INTERVAL_MS` environment variable. The
+   per-fetch cap is likewise configurable
+   (`MxGateway:Alarms:MaxAlarmsPerFetch`, default 1024).
+
+   One snapshot rule matters when reading the capture below: a fetch
+   that returns exactly the cap is treated as **truncated**, and the
+   worker *merges* it into the retained snapshot instead of replacing
+   it. `GetXmlCurrentAlarms2` caps its reply with no "more available"
+   flag, so a capped reply is authoritative about presence only —
+   alarms it had no room to mention are retained rather than allowed
+   to vanish, because their disappearance is what the gateway's
+   reconcile pass reads as a clear. Only a sub-cap fetch replaces the
+   snapshot wholesale and can therefore clear alarms. See
+   `docs/DesignDecisions.md`, "Alarms — a capped snapshot fetch never
+   implies a clear".
 2. **Hook AVEVA's internal window.** Discover AVEVA's own window
    (`hwnd=0x18032E` in the probe), `SetWindowsHookEx` or
    `SetWindowSubclass` on it, and intercept WM 0xC275 on AVEVA's