docs: sharpen the series-3 histogram open item — dropped intervals, not wrong values

Re-measured properly.  The first pass compared h5 max against the ASCII
header PPV and reported "26% of channels miss the peak".  The histogram
ASCII actually carries a full per-interval data table (Tran/Vert/Long
peak + freq + PVS per interval), which is real ground truth, so the
comparison should have been per-interval from the start.

Per-interval result, n=1196 series-3 histograms:
  - decoded VALUES are right: 1031/1196 (86%) match within 1 LSB across
    the overlapping prefix
  - the interval COUNT is short in 1195 of 1196 files: median 1 missing,
    1088 short by 1-2, 65 by 3-10, 39 by 11-100, 3 by >100 (max 205)
  - decoded max falls below the device PPV in 169/1196 files (14%), not
    26% — that happens when a dropped interval held the peak

So it is a termination bug in histogram_codec.decode_histogram_body,
the same family as the waveform-walker truncation fixed earlier today,
rather than mis-decoded interval values.  Series-3 only; there is no
preserved series-4 ASCII in the snapshot to compare against.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HgTe8CamXAHcAmaQ6QNcog

CLAUDE.md

@@ -276,12 +276,19 @@ Corpus result, end to end through the production path:
   anchor count — `01 00` records appear with both 2- and 4-byte anchor
   fields in the same file.  Examples: `BE12599/N599LPNB.JF0W` @1155,
   `BE12599/N599LPWJ.980W` @849, `BE9558/K558LOF2.820W` @1485.
-- **Histogram codec misses the peak interval** — 301 of 1141 series-3
+- **Histogram codec drops trailing intervals (series-3)** — the
-  histogram channels (26%) decode a peak below 95% of the
+  per-interval *values* are right: measured against the histogram ASCII
-  device-reported PPV (one reads 0.0300 against a device PPV of 0.1200,
+  data table (Tran/Vert/Long peak + freq + PVS per interval), 1031 of
-  exactly 1/4).  Not a scale error — that would be a uniform 2.34%.
+  1196 files (86%) match within 1 LSB across the overlapping prefix.
-  Lives in `histogram_codec.decode_histogram_body`, untouched by the
+  The interval **count** is short in 1195 of 1196 files — median 1
-  2026-08-25 waveform pass.
+  missing; 1088 short by 1–2, 65 by 3–10, 39 by 11–100, 3 by >100 (max
+  205).  When a dropped interval holds the event peak, the decoded max
+  falls below the device-reported PPV: 169/1196 files (14%).  A
+  termination bug in `histogram_codec.decode_histogram_body` — same
+  family as the waveform-walker truncation fixed 2026-08-25, and
+  untouched by it.  Note: the histogram ASCII carries a full
+  per-interval table, so this has proper ground truth available (1211
+  files in the prod snapshot).
 - **Micromate (UM-series) IDF decode is ~1000× low** — e.g.
   `UM11402_20260406130113.IDFW` gives a Tran peak of 0.0009 in/s against
   a device-reported 1.1168.  The Thor IDF path decodes sanely, so this

docs/instantel_protocol_reference.md

@@ -3037,7 +3037,7 @@ The `.bin` files produced by `s3_bridge` are **not raw wire bytes**. The logger
 | **Sensor Check dropdown byte location** — byte offset in 1A compliance config payload for the "Sensor Check: Before monitoring / After each event / Disabled" setting is NOT YET LOCATED. Confirmed: unit always runs with "Before monitoring" set. Need a capture with "Disabled" to diff. | MEDIUM | 2026-04-08 | Still open |
 | **RV55 DCD/DTR default** — newer Sierra Wireless RV55 firmware does not assert DCD/DTR by default, so the MiniMate Plus never detects TCP disconnect and stays idle instead of resuming monitoring. Root cause: RV55 ACEmanager `DCD Control` setting. Workaround not yet found. | MEDIUM | 2026-04-11 | Still open |
 | **Variable-prefix segment descriptors** — 3 of 75 ground-truth events still truncate. The walk reaches a segment header whose channel-id field is preceded by a *variable-width* prefix (2, 4 or 6 bytes observed; the standard tagless form always has 4), carrying an `01 00` marker instead of `02 00`. The marker is **not** simply an anchor count — `01 00` records appear with both 2- and 4-byte anchor fields in the same file, so prefix width and marker are not yet reconciled. Examples: `BE12599/N599LPNB.JF0W` @1155, `BE12599/N599LPWJ.980W` @849, `BE9558/K558LOF2.820W` @1485. | MEDIUM | 2026-08-25 | Still open |
-| **Histogram codec misses the peak interval** — 301 of 1141 series-3 histogram channels (26%) decode a peak below 95% of the device-reported PPV; one example reads 0.0300 against a device PPV of 0.1200 (exactly 1/4). This is not a scale error (that would be a uniform 2.34%) — the interval carrying the peak is being missed or mis-attributed. Affects `histogram_codec.decode_histogram_body`, untouched by the 2026-08-25 waveform pass. | MEDIUM | 2026-08-25 | Still open |
+| **Histogram codec drops trailing intervals (series-3)** — measured per-interval against the histogram ASCII data table (which carries Tran/Vert/Long peak + freq + PVS per interval), n=1196: the decoded per-interval **values are right** — 1031/1196 (86%) match the ASCII table within 1 LSB across the overlapping prefix — but the interval **count** is short in 1195 of 1196 files. Median 1 interval missing; 1088 files short by 1–2, 65 by 3–10, 39 by 11–100, 3 by more than 100 (max 205). When a dropped interval is the one holding the event peak, the decoded max falls below the device-reported PPV — 169/1196 (14%) of files. This is a termination bug in `histogram_codec.decode_histogram_body`, the same family as the waveform-walker truncation fixed 2026-08-25, and it was untouched by that pass. | MEDIUM | 2026-08-25 | Still open |
 | **Micromate (UM-series) IDF decode is ~1000x low** — e.g. `UM11402_20260406130113.IDFW` decodes a Tran peak of 0.0009 in/s against a device-reported 1.1168. Distinct from the Thor IDF path, which decodes sanely. Suspect a different per-count LSB or a body offset that does not hold for UM-series files. | MEDIUM | 2026-08-25 | Still open |
 | **Thor IDF per-count LSB** — after the 32000 geo full-scale correction, series-4 Thor peaks sit at a median 0.983 of the device-reported peak (was 0.960 under 32768). Closer, but the residual ~1.7% suggests Thor uses its own per-count LSB rather than the BW 16-count/0.005 in/s convention. A code comment in `sfm/waveform_store.py` claims Thor's LSB is 0.0003 in/s, which would predict Thor reading *high* — the measurement shows the opposite, so that comment is unverified. | LOW | 2026-08-25 | Still open |