harness: measure a runner's MLLP ingress rate instead of pass/failing one point

[wshallwshall]

Diagnostic tooling for item #320. Two new files plus a three-line note; nothing existing changes behaviour.

Why

test_load_runner red the required windows-2025 leg twice on main (9b03057f, 56f7d240) with byte-identical counters — 90 sent, 44 acked, 46 stranded, 52 read — on runs that lost nothing. #115 widened the reconcile's stranding budget so a saturated-but-lossless run stops failing. That fixed the symptom and says nothing about the cause.

The open question is whether the windows-2025 image is slow or Windows generally is, and a pass/fail test at one fixed offered rate structurally cannot answer it. That's a rate, not a verdict.

What this adds

• harness/load/ingress_probe.py — sweeps offered rate, prints one machine-parseable RESULT line per run.
• .github/workflows/ingress-rate-probe.yml — workflow_dispatch only, runs it across ubuntu-latest / windows-2022 / windows-2025 and writes a side-by-side table to the step summary.

ubuntu is the control, not a deployment target: it establishes what "not saturated" looks like on hosted hardware so a slow Windows row can be read against something.

The correction this PR is built on

I have to flag this, because I got it wrong first: I ran 600/s once on a developer box, got 456 stranded of 900 (50.7%) — a near-exact match for the windows-2025 signature — and wrote it up as a clean reproduction.

Four repeats of the same command on the same box then produced 0 stranded, every time. The outlier was taken while an unrelated test suite was running.

So stranding here is a contention artifact, not a clean function of offered rate, and n=1 is not a measurement. Hence --repeat, defaulted to 3, with the correction written into the module docstring so the next reader doesn't redo it.

What survives: an unloaded box strands zero at up to 10× the CI profile's rate, while windows-2025 stranded ~51% at the profile's own 60/s, twice, byte-identically. That's weaker than what I first claimed and still worth measuring properly.

Deliberately not a gate

No pull_request trigger, so it can never report on a PR or become the required-but-absent trap. And it is structurally unfit to gate anything: the probe exits 0 even when the reconcile fails, because a machine too slow to keep up is the finding, not an error. Recorded in .github/required-contexts.txt alongside the other advisory workflows.

It also prints no derived per-second figure. engine_read / wall looks like a service rate and isn't one — wall includes the stop grace, drain and settle-poll, so it lands at ~25/s whether the run offered 60/s or 600/s. I had that in a draft and removed it; reporting offered/ingested/stranded and letting the reader compare rows is honest, a fabricated rate is not.

What it still cannot answer

Both legs are hosted VMs. A slow-2025 / fast-2022 result narrows the cause to the 2025 image — it cannot clear or convict Windows Server 2025 as a deployment target, because a hosted image can be slow for reasons a deployed server isn't (Defender policy, VM disk backing, noisy neighbours).

Only the self-hosted WS2025 rig settles that, and it is unregistered — actions/runners returns total_count: 0 and selfhosted-win2025-sql.yml has never run. That remains the decisive experiment, and it needs the VM brought up.

Verification

• ruff check + ruff format clean; pre-commit passed including the Actions linter.
• YAML asserted to have no pull_request trigger.
• Probe exercised locally at 60/s and 600/s, and with --repeat.
• 222 workflow/required-context/posture guard tests pass, including the invariants that police the advisory-workflow list.