Follow-ups to #247: pin raised-interval guard and repeated cut, document false-change trade-off #270

Follow-ups from the round-2 review of #247 (#245 M1, merged as ae126374). Findings N1–N5 are in the review comment on #247.

Test gaps: surviving mutants

1. N1 — the guard against a false "raised" read is not pinned. A gap at exactly 1× among the newest 3 fitting gaps must break the run (if k == 1 … return 0 in advertIntervalRaised). If that gap is skipped instead, the mutant survives.
   • Add a _RaisedInterval case: on 12 h, a series ending in gaps of 24, 12, 24, 24 h (oldest first) must still give 12 h.
2. N2 — the repeated cut is not pinned. The mutant that makes only one cut survives.
   • Add a double-raise series that expects the final interval: zero-hop 60 → 120 → 240 min, or flood 12 → 24 → 47 h.
3. N5 — the edges of the zero-hop 2-min candidate band are not pinned. Widening the band from ±10 % to ±20 % survives.
   • Add band-edge cases.

Docs

4. N3 — document the false-change trade-off next to the sparse-coverage limitation in docs/api-spec.md. With an unchanged interval, if the newest 3 heard gaps are the same multiple (every 2nd or 3rd advert lost), the result is k× at medium confidence on 4 adverts.
   • Optional: report low while the estimate rests on a short post-change segment.
5. N5 — fix the OpenAPI text. The NodeAdvertIntervals description says "the median of the fitting gaps", but the estimate is the median of gap/k, as the docs already say.

For M2 (not code here)

6. F7 / N4. A flood advert re-arms the zero-hop timer (MyMesh.cpp:1294-1306).
   • If the flood interval is ≤ the zero-hop interval, zero-hop never fires.
   • If Z < F ≤ 2Z, zero-hop reads as F at high confidence.
   • Carry both cases into the M2 analytics plan on feat(nodes): estimated advert intervals (flood / zero-hop) per node, then mesh-wide settings analytics #245.

Acceptance

• The new tests kill mutants R1, R2 and C1 from the review.
• The docs and OpenAPI text match the code.