fix(cancel): report a cancelled job as cancelled, not as a failure

[StuartCameronCode]

Third attempt at the same report. The first two missed the actual cause, so this
one starts from the evidence.

Cause

The worker sends complete(false) on its way out of a cancellation as well as
on a real failure, and _handleStdoutLine builds that into a CompletionResult
with no cancelled flag — so it defaults to false.

_pendingCompletion is therefore always set when the worker exits, which made
the previous fix inert: it put cancelled: _cancelRequested in a ?? fallback
behind _pendingCompletion, where it could never be reached. Cancelling still
looked exactly like a failure.

That distinction drives the queue. _handleQueueItemCompletion stops on
cancelled, but on a plain failure it marks the item failed and calls
_processNextItem(). So cancelling silently started the next job and left
_isQueueProcessing true — and the next conversion the user asked for sat on
"processing" with a spinner and no progress, because the queue believed it was
already busy.

Fix

The decision is now a pure function, WorkerManager.completionFor, with the
cancellation check first, so it overrides the worker's own report rather than
filling in for it.

Why it is extracted

Both previous attempts were verified by tests that read the source. Those passed,
and the bug shipped twice. This is testable directly, and the decisive case —
cancelled with a pending complete(false), which is the only case that
actually occurs — fails against the shipped logic and passes against this one.

The stale source-scanning assertion is reduced to checking the handler routes
through completionFor and hands over the flag; what it was trying to assert is
now covered by behaviour instead of by text.