Parallel test execution on Rapira workers

[roxblnfk]

Testo runs tests sequentially in one process. The usual ways to go parallel in PHP are pcntl forks (no Windows, blocking IPC) or spawning child processes with hand-rolled plumbing over pipes or files. Both work, both are ugly, and both leave the coordination logic in PHP where it is slowest.

An idea worth exploring: use Rapira as an execution backend. Rapira already owns a pool of PHP workers. A master worker would schedule tests, N workers would run them, results would flow back over a fast in-process channel. Discovery (glob by pattern) and report writing could move to the Rust side too, since both are hot paths.

What this would need from Rapira is discussed there: rapira-rs/rapira#123, with the channel primitive it rests on in rapira-rs/rapira#121. This issue is about the Testo side of the same conversation.

Questions I don't have answers to yet:

• Where does the boundary sit: a separate runner project that depends on both Testo and Rapira, or a Testo plugin that talks to a Rapira binary?
• The binary has to be fetched and installed by the runner itself, with a fallback to a pure PHP path when that fails. What does the fallback look like: sequential run, or a proc_open-based poor man's parallelism?
• How do interceptors, reporters and the report bus (RFC: testo/reporter — pluggable report bus #121) behave when tests run in several processes? Aggregation has to happen somewhere.
• Test isolation guarantees: shared state, static caches, database fixtures. Which of those does the runner promise and which are left to the user?

Opening this to think out loud, nothing here is settled.