docs: the sample budget in samples per signal, the memory limit and the planner probe lines

Converts every --buffer-mb / buffer_mb mention to --buffer-samples / buffer_samples,
records the unit change as a deviation (README, SPECS, CLAUDE.md), documents the
buffer: and planner: dump lines and the new Preferences row, and updates the help
pages and the help-shot script.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

SPECS.md

@@ -42,9 +42,18 @@
 The following were built differently from what was asked for, each for a reason `README.md` states
 in full:
 
-- **`todo.md` item 2 — relative timing.** Implemented as `--relative-time`. The retained history
-  in this mode is **41.943 s** against the default **83.886 s** (measured at 100 kS/s, 4 channels,
-  `--buffer-mb 200`): exactly half, because a second f64 ring for absolute time raises a tick's
+- **The buffer is budgeted in samples per signal, not megabytes** (line 1 asked for "default 200MB
+  each, configurable as cli argument"). `--buffer-samples N` (default 10M, k/M/G suffixes) is the
+  number of samples kept for every acquired signal and for the shared time ring, rounded **down** to a
+  power of two ("up to"; 10M gives 8 388 608), and a separate application setting, `--memory-limit-mb`
+  (default 8192, also in Preferences), is the hard ceiling on the ring bytes, halving the sample budget
+  when the rings would not fit. The retained history therefore no longer depends on the channel count
+  or on relative time. There is no `--buffer-mb` and no compatibility shim; a stored `buffer_mb` is
+  ignored. The "2 identical buffers" were already a single ring plus latched snapshots (see below).
+- **`todo.md` item 2 — relative timing.** Implemented as `--relative-time`. *As first built* (under
+  the old byte budget; superseded by the item above, where both modes keep the same span and only
+  the memory differs) the retained history in this mode was **41.943 s** against the default
+  **83.886 s** (measured at 100 kS/s, 4 channels, `--buffer-mb 200`): exactly half, because a second f64 ring for absolute time raises a tick's
   cost from 24 to 32 bytes — a third more — and `Partition::time_capacity` is floored to a power
   of two, so a third more weight costs a full halving. The design document and the implementation
   plan both put the cost at ~22%, which is wrong; the per-byte figure of 75% is wrong for the same