Wait for this action's report, not any run's

[amrali-eg]

First lead on EC-28, the unexplained phase A timeout.
This does not close it - the original failure was never reproduced, so this
removes a known weakness in the failing path and makes the next occurrence
legible. It does not show that this was the cause, and the entry stays open.

No production code changes; MainForm was read and not edited.

What was wrong

WaitForMainReady accepted any of the seven headlines IsFinalConversionStatus
matches, so it asked has some run ended rather than has the one just started
ended. A status outlives the action that wrote it - the window clears it only
when the next action starts - so the wait could be satisfied by the previous
action's report and return before the current one had finished.

Every phase drives one action per window today, which is the only reason that has
not bitten. It is EC-26's shape in the one helper that
fix did not reach, sitting directly in the path that failed.

Now

Each caller names the headline its own action produces. That mapping was measured
rather than assumed, by instrumenting the helper and reading a full suite run:

Caller	Expects
CancelReview	Conversion cancelled
Proceed	Conversion complete
ProceedExpectingWarning	Conversion did not run

The warning path reporting Conversion did not run rather than Conversion stopped is the sort of thing reasoning alone would have got wrong.

The timeout also records what could still be established - whether the process is
alive, whether the main-window handle reads, whether the review is gone, and
whether the status bar can be found and read. EC-28's one failure showed window
chrome and nothing else and left none of those knowable afterwards. Each fact is
gathered separately so one unreadable answer does not cost the others.

Evidence

Control	Result
Expect a headline EC never writes	Times out against a status reading Conversion cancelled. No files were modified. - which the previous code accepted as idle
Same control's diagnostics	Process alive: yes; main window handle: 26610754; review present: no; status bar found: yes; status bar readable: yes.
Full suite	10/10
Unit tests	756 passed

The mutation required a successful build before running, and the source was
restored byte-for-byte afterwards.

Not in this PR

Three findings against the cancellation state machine merged in #97 are being
handled separately, in order: reading the final status before attempting another
press, reporting Conversion failed as a conversion failure rather than as
"cancellation was not exercised", and renaming pressed so an uncertain delivery
is described as attempted.

🤖 Generated with Claude Code