Karma singleRun timing vs ChromeHeadless process readiness

Karma's singleRun mode aims to execute a test suite once and exit, which is essential for deterministic CI pipelines. The integration boundary between the Karma runner and the ChromeHeadless launcher introduces a race condition: the runner may terminate before the browser process has fully initialized and reported results, especially on slower CI agents. This behavior is compounded by the requirement that actual browser binaries be present on the host, making version parity between local development and CI environments a persistent source of non-determinism. While the browsers array in karma.conf.js pins a specific launcher, it does not govern the handshake timing between the server socket and the spawned browser instance.

1. What configuration or lifecycle hooks ensure the runner waits for the browser's ready signal before starting the test timer?
2. Can the launcher protocol be extended to emit a deterministic startup-complete event that singleRun respects?
3. How should version-pinning strategies for the browser binary be encoded in the repository to guarantee identical rendering behavior across machines?