research: attribute a blocked test-module startup before changing the runner

[mohanagy]

User story

As a maintainer, I want to know why a requested test module did not execute, so that I can choose a causal correction instead of repeatedly rerunning incomplete suites.

Acceptance criteria

• Select one recorded failure and declare the execution profile; distinguish failure to start from a timeout inside an executing test.
• Use existing requested-versus-executed accounting and lifecycle diagnostics, retaining the first failure.
• End one bounded investigation with a supported causal correction or an explicit unresolved result.
• Do not treat a passing retry as proof of a fixed cause or justify a new general runner or global worker/time-budget changes without evidence.

Status and scope

Deferred. Activate only if a specific recorded worker-start failure prevents necessary validation. No execution is authorized by publishing this story.

This tracks the worker-start portion of #710. It does not absorb every intermittent test or the separate background-refresh/stdio-session timeout cases, and the recovery-clock correction need not wait for it.

Reuse the existing worker-failure guard and requested/report matching. Preserve the original diagnosis.

Identical-code passing reruns demonstrate intermittency; they do not establish a scheduling-only cause or exclude a load-sensitive product race.