feat(web-viewer): hide flood hop buckets under 0.1% of the series

The flood tail decays over roughly twenty hops in bars under a pixel
tall. Buckets holding less than 0.1% of the series are no longer drawn,
which on the live mesh takes the axis from 64 buckets to 44.

What is left out is reported, not dropped: a line under the chart reads
"1,467 further flood packets (0.9%) sit in 20 hop buckets below 0.1%
each, and are not drawn." An unannounced cut would be the same lie as a
silently truncated category list.

Two details that matter for honesty:

Percentages still divide by the whole series, never by the drawn subset,
so removing the tail cannot inflate the bars that remain. The smallest
surviving bar on live data is 0.118%, which is what it was before.

A withheld bucket inside the axis is null rather than zero. Zero would
claim no packets travelled that far, which is a different and false
statement; null draws nothing and says nothing. Padding gaps stay zero,
because there it is true.

The threshold applies to the flood series only — the node series is
small enough to draw in full — and the underlying computation still
covers the whole 64-hop protocol range.

docs/web-viewer.md

@@ -168,6 +168,12 @@ packets, so each is drawn as a share of its own total. Flood packets carry no
 sender identity, which is why they cannot be reduced to a shortest path per
 node the way adverts can.
 
+Flood hop buckets holding under 0.1% of the series are omitted, because that
+tail decays over roughly twenty hops in bars thinner than a pixel. The number of
+packets withheld is printed beneath the chart, and percentages stay shares of
+the full series so that hiding the tail cannot inflate the remaining bars. The
+node series is shown in full.
+
 **Neighbour signal is reported only where two sources agree.**
 `complete_contact_tracking.hop_count` is not a reliable direct-neighbour marker:
 on a representative database it claims 800 zero-hop contacts while only 68 have