Push telemetry is only delivered when flush() runs. HTTP requests flush on kernel.terminate and
ConsumerRunner flushes inside its own loop — with a comment explaining exactly why. The outbox
relay is the same shape of process and got neither: a daemon whose ConsoleEvents::TERMINATE fires
only at process exit, which never happens. Everything recorded inside the loop accumulated in
memory until the worker was restarted, then went in the bin.

That is not theoretical. vortos_aws_ses_send_total is recorded by the SES middleware, which runs
in this process, and had never once reached the metrics store on a production installation that
demonstrably sends mail — notification_deliveries_total{channel="email"} counts the same sends
from a consumer process, which does flush, and they are there. Email deliverability was the one
signal with no coverage, on the system whose defining incident was mail silently not being sent.

Same throttled flush as ConsumerRunner: once per interval rather than per iteration, forced on the
way out so a clean SIGTERM does not discard the final window, and outside the poll's catch block
because a failed poll still produced telemetry worth having — the failure path is exactly when
someone is watching. A flush failure is logged and swallowed: losing a metrics sample is
acceptable, losing a customer's message is not.

The while.alwaysTrue baseline entry goes with it; wrapping the loop in try/finally makes the
condition analysable, so PHPStan no longer reports it.

Split from 1a1fb1ab3ef1b48b7500f46c55f7a045be3231d4