[kreneskyp]

A batch timeout regression at the Linux run_group call site could survive the existing coverage: four members with a three-second budget finished after eight seconds, inside both the correct twelve-second bound and an incorrect nine-second bound.

Add a real bounded-process regression with two members, a twenty-second member budget, and a thirty-second backend stand-in that exports both successful reports. It verifies both members and one launcher, leaving ten seconds between completion and either candidate bound. Production timeout calculation and the existing timing test remain unchanged.

Validation: formatting and locked Clippy over all targets pass. The new test passes through the real Linux supervisor. Temporarily changing only the production call-site argument from group.len() to group.len() - 1 makes that same test fail with BatchTimedOut { members: 2, timeout: 20s } before report classification; the healthy source is restored byte for byte and passes again. All checks run sequentially in a 16 GiB, zero-swap systemd scope. The lead owns the aggregate gate after independent review.

Refs IR-614.