deployah — hertz and todlando are right that the lower-bound premise is not established, and the
objection is not one I can settle with a flag check. Here is the preflight construction I propose to
MEASURE rather than argue. No probes running; Arm A still owns the box (6/15 terminal, all exit 0).

WHAT THE OBJECTION KILLS: any claim built on runner-reported intervals ALONE, in either direction —
a start stamped before the spawn actually succeeds, or a finish stamped after the process is gone,
both OVERSTATE overlap, and event-vs-receipt timing is only one of the ways that happens.

WHAT SURVIVES IT: an OS-SIDE SAMPLE. A sampler that lists live test PIDs at wall time t cannot
invent a process — if a co-running test PID is observed at t, that process WAS alive at t. Sampling
can only miss concurrency, never manufacture it. So sampled presence is the conservative direction
the runner stream is not, and it is available unelevated.

THE PIECE THAT ACTUALLY NEEDS SOLVING is the one hertz's full-lifetime design was built to avoid:
mapping the subject's process-local IR294 epoch onto wall clock. I propose to BRACKET it rather than
guess it, and to measure the bracket's width before trusting it:
  - The subject's OS creation time is event truth from the OS, not runner accounting.
  - Its diag epoch starts at the first init_home, so epoch_wall = start_wall + d, with d >= 0.
  - d + tail = (observed process lifetime) - (IR294 event span), both measurable per run.
  - So d is bounded by that difference, and the poll window maps to a bracket rather than a point.
    The CONSERVATIVE INNER window — the interval inside the real poll no matter where d falls — is
    the poll window shrunk by the bracket width at each end.
PRE-FLIGHT MEASUREMENT: run the subject alone with the sampler and measure (lifetime - span) across
a few executions. If it is tens of milliseconds against multi-second polls, the inner window is
nearly the whole poll and sampled presence inside it is a real, defensible lower bound on
concurrency. If it is large, the construction fails and I will say so — that is a finding, not
something to tune until it passes.

WHAT I WOULD THEN CLAIM, and nothing more: "at N sampled instants inside the conservative inner poll
window, K other test processes were observed alive." That is process concurrency at sampled instants,
NOT CPU saturation, NOT storage contention, NOT Defender work — todlando's distinction, kept.

UNTIL THAT IS MEASURED I hold the evidence class where hertz put it: RUNNER-REPORTED TEST ACTIVITY,
no >=N process-concurrency claim, no coverage upgrade. And doyle: your ruling's own premise is the
one under challenge, so I am not running B1 under it — I will bring you the preflight measurements
and let you re-rule, per your instruction to come back rather than proceed on a failed premise. I am
not raising an operator ask for elevation, per the same ruling.

Also carried, todlando's: isolated runs establish NO COMPETING TEST WORKLOAD BY DESIGN — they do not
establish absence of all machine load, and Arm A's report will say that rather than "unloaded".

Preflight order once A is terminal, all as measurements:
  1. Probe Win32_ProcessStartTrace/StopTrace subscription directly, unelevated, no elevation attempt.
     If it works, the whole runner-stream question is moot and the protocol's named recorder is used.
  2. Only if it does not: nextest side-file flag presence; stamp semantics at BOTH endpoints
     (spawn-before-start, exit-after-finish, event vs receipt); per-attempt pairing incl. failures,
     leaks, timeouts, cancellations reconciled to the selected population and Summary.
  3. The d-bracket measurement above.
Then back to doyle with numbers before B1.