feat: use burst loss in the profiles and timelines, and give it a rig

[donislawdev]

Follow-up to the burst-loss engine: the shipped profiles and timelines now use
it, the licence question behind the new sources is settled in writing, and the
feature has a rig that does not take the tool's word for anything.

The presets, and the split is the mechanism

Radio loss comes from fading, interference and handovers, which take the channel
away for a stretch. Wired loss is queue overflow, and tail drop on one flow is
close to independent. So weak_wifi, cafe, metro, inflight, 3g,
roaming, satellite, good_wifi and terrible carry a run length, and dsl,
modem56k, bufferbloat, distant, perfect, 5g and lte do not. Loss
rates are unchanged.

New source [WIFI-BLL] - da Silva and Pedroso, Sensors 22(22):8592, 2022,
doi:10.3390/s22228592: a real 802.11b/g/n network over 24 600 minutes, with mean
burst loss lengths of 3.00 packets in the good channel state, 4.66 in the worse
intermediate and 5.67 in the bad one. The three Wi-Fi presets take those
per-state means.

🔴 Deliberately NOT the 5.37 the same paper reports for the whole trace, and
the reasoning is recorded next to the table because it looks exactly like
diligence. That mean carries a standard deviation of 31.68 and a longest burst of
8853, so it is dragged upward by rare enormous bursts. Our chain is geometric and
memoryless: it cannot produce "mostly short, occasionally 8853", so fitting its
mean to 5.37 would deliver far more medium bursts than the measurement ever saw.

leo is left alone on the strength of a source, which is the strongest reason
on the list: [STAR-CON] measured the 15-second reconfiguration queueing packets
rather than dropping them, which is why that preset carries a spike and no
outage. Bursting it would contradict its own citation.

Checked before touching a value: a reproduction command emits explicit numbers and
never --preset, so commands saved by an earlier release are immune to this; the
highest preset loss is 10%, so no preset can reach the clamp; and the derived gap
lands between 114 and 400 packets, so a short session sees several runs.

The licence question, settled

Both new sources were checked at the source rather than assumed, and the answer is
written into the code so nobody checks it twice.

• [WIFI-BLL] is open access under CC BY 4.0, copyright the authors. Clean
  twice over: individual figures are facts and carry no copyright at all, and even
  if they did, CC BY permits reuse with attribution, which is given with authors,
  venue and DOI. No wording reproduced, and the underlying trace is not ingested,
  which is the line that matters.
• [E-MODEL] is an ITU-T Recommendation and ITU reserves its rights in the
  text. None of that text is here: a definition and a threshold, restated, used as
  a sanity anchor rather than as the source of any value.
• The MMB 2008 paper is not open access. What is taken from it is an idea plus
  an observation about its printed formula. The formula in this repository was
  worked out here.
• tc netem is named, not used. It ships under GPL-2.0 as part of iproute2,
  which convention 35 forbids as a dependency - and nothing depends on it. Named so
  a reader knows the model has a widely deployed implementation to compare against.
• Nothing belongs in THIRD-PARTY-NOTICES.md or licenses/: those carry what
  the build ships, and a citation in a comment ships no third-party work.

Verified mechanically as well as by reading: no dependency, licence file or notices
entry changed anywhere in this work, and a scan of the tracked tree for distinctive
wording from every source read finds two hits, both deliberate - the model's own
name, and the CC BY notice quoted because that licence asks for exactly that
attribution.

The scenarios

Same split, same reason. cafe-wifi and mobile-lte-to-3g are radio stories and
get run lengths; congested-vpn, overloaded-game-server, failing-dns,
upload-drop-midway and blocked-endpoint are queue and path stories and keep
their loss evenly spread.

New: scenarios/same-loss-in-runs.json holds 5% loss for the whole run and
changes nothing else, delivering it evenly and then in runs of 5, 15 and 40. It is
the only file in the set where the loss RATE is constant, so whatever breaks is the
shape rather than the amount - the question this impairment exists to ask and the
one a rate alone cannot. Accepted live: each step announces its own run length and
its own expected distance between runs.

Edited line by line rather than through a JSON re-dump, because these are hand-laid
timelines with one step per line.

A rig, outside git as rigs are

internal_tools/probe_burst_loss_truth.py, registered as burst. It is the only
check on this feature that does not ask the tool: a client sends numbered UDP
datagrams to a local collector, and the run lengths come from the GAPS in the
sequence that arrived. UDP because TCP retransmits a run of losses into TIME and
leaves no gaps at all; one direction because WinDivert presents loopback as
outbound either way, so an echo would advance the chain twice per round trip.

First run, elevated, real driver, 20 000 datagrams a case:

case	observed run	asked	delivered loss	expected	runs seen	engine says
control	-	-	0.00%	0%	-	-
even	1.06	1	4.79%	5.00%	907	0
runs	9.37	10	4.31%	5.00%	92	92
long_runs	28.76	30	4.75%	5.00%	33	33
clamped	5.07	5	83.53%	83.33%	3294	3294

The observed run counts match the engine's counter exactly, and the two numbers
are produced by nothing in common. 🔴 What it deliberately cannot see is the
per-direction claim: there is only one direction on loopback as far as the driver
is concerned, so the property that needs two stays in the unit suite.

Its baseline is not recorded yet, on purpose - baseline.py refuses a
reference taken from a branch, because a squash merge throws that commit away.
After this merges, on master: python internal_tools/baseline.py record --only burst.

Verification

• 369 tests green across every guard this work touches, plus ruff, mypy, the
  code-shape ratchets and the public-text guard.
• The five burst-loss mutation entries still all caught.
• Preset values accepted live through the CLI, and the sampling trap showed up
  again on the way: cafe measured 2.29% against its 3% over 51 runs and
  3.45 / 3.07 / 3.50% over about 200. Repeating before believing is the only
  reason that is a note and not a bug report.
• The rig-bookkeeping check caught an unclassified probe from the previous branch,
  which is the check working.

Not done, said out loud

• Rigs still run at a release rather than per chunk, so only the new one was run.
• 5g and lte lose 0.1-0.3%, little enough that a run length would be an
  unsourced number nobody would see act. They are candidates, not oversights.
• Nothing external gives a run length for cellular, satellite or rail, so those
  values are marked as judgements at the value, the way the table already does.

🤖 Generated with Claude Code