marilib: make the metrics probe a usable measurement instrument

[geonnave]

Preparing marilib to measure latency and PDR for a paper campaign turned up
several things that made the numbers wrong or unreadable rather than merely
inconvenient. This fixes them and adds the firmware tooling the campaign needs.

The probe stream had to stop scaling with the fleet

The probe interval was per node, so the offered probe load grew linearly with
the node count: a fixed 5 s/node is 20 probes/s at 100 nodes but 2 at 10. That
makes the instrument itself the variable under test when the fleet size or the
schedule changes.

--probe-every now cadences in slotframes instead of seconds, so the probe
share of downlink stays roughly constant across schedules (N/(K x d_down) is
within a few percent of 4.6/K for tiny through huge). -i still sets a
wall-clock interval when that is what you want. The cadence is derived lazily,
once the gateway has actually reported its schedule, because deriving it up
front meant a fixed deadline that could abort a run before the first beacon.

--load now means total downlink occupancy: the load generator subtracts
the measured probe rate, so passing 75 puts 75% on the link rather than 75%
plus whatever the probes were already using. Recomputed per packet, since the
probe stream grows with the node count.

Also removes an upper bound in set_interval that compared a value in seconds
against a deque length, and so silently clamped long intervals.

Late probe replies were being discarded after being counted

The edge stamped edge_rx_ts_us only after matching a reply against the
pending-probe table, so a reply arriving after its entry had been evicted was
dropped without a timestamp - censoring exactly the slow tail that a latency
distribution is about. Stamping happens before the match now, so a late reply
still reaches the cloud carrying usable data.

The logs could not reconstruct a run

node_metrics.csv gained the raw counters (gw_tx_count, gw_rx_count,
node_tx_count, node_rx_count, edge_tx_count, edge_rx_count) and the
per-hop latency halves, so PDR can be computed after the fact from counter
deltas rather than trusted from a running average. This matters because a node
rejoining zeroes the gateway's counters but not its own, and only the raw pairs
let an analysis segment around that.

metrics_setup.csv records the run's parameters, the write-once guard on it is
gone (it prevented recording a cadence derived after startup), and the metrics
CSVs are flushed at the sampling rate so a run can be analysed while it is still
going.

TUI and CLI

The TUI shows the probe budget as a share of downlink, the measured probe rate
with a retry indicator, uplink slot utilisation, and raw link saturation in both
directions - enough to see a saturating link during a run instead of at the
analysis. MQTT credentials now come from the environment.

Firmware tooling

flash.sh lists only the role's own device family, reports other-family boards
separately so a missing board is distinguishable from one plugged in under the
wrong role, and gains --erase-only and a both role.

build-schedules.sh builds one gateway net-core image per schedule. It edits a
single line to select the schedule and restores the file byte-for-byte on exit,
including through a failure, because a bench tree legitimately carries local
edits that must survive the build.

Validation

The Python changes have run continuously on the bench: 100 nodes at 2 m and
10 m, four traffic loads, and a schedule sweep across tiny/medium/big/huge, with
the counters cross-checked against the sliding-window PDR marilib reports
independently. hatch fmt --check and hatch test pass; firmware changes are
scripts only, no compiled code is touched.