States the host case runner's wall-clock bounds

[johnnyt]

Refs: st-h4sp

What changes

Mix.Statifier.Corpus.HostCase waits for each configuration by polling the
session, and every wait is bounded by the wall clock: the configuration
deadline (@configuration_deadline_ms, four seconds), the window a pending
timer gets before the next event (@settle_window_ms, 100 ms), and the
default five-second timeout of each Statifier.Session.status/1 and
Statifier.Session.snapshot/1 call the wait makes. The moduledoc described
the waiting but not the bounds.

A new moduledoc paragraph states each bound, its reason (every case must
end with a verdict, so the wait is bounded by the clock rather than by the
session) and its cost: a session held longer than a bound, such as one
inside a Basic HTTP POST that Statifier.Send.BasicHTTP.Transport.Httpc
bounds at five seconds of its own, fails the case whatever its document
does, and running it again on an idle machine tells load from a real
disagreement.

This is the documentation route the bead's acceptance allows, decided by
the conductor under a standing consent, 2026-10-10: the bound is stated
with its reason and the runner is not rewritten. No code changes; no
changelog fragment (corpus tooling).

Gate

Full mix quality (mix gate.verify) green on this commit's tree, and the
merge profile (mix quality --profile merge) green, the ADR judge skipped
because no file is in a judged scope.

Review

Tier: gate (a moduledoc paragraph). In-turn review checked each stated
bound against the module's attributes, Statifier.Session.status/1 and
snapshot/1 (plain GenServer.call/2) and the Httpc transport's
@timeout_ms, and found nothing to change.