…p 3 (#1573)

RunResetAsync publishes CurrentProgressStep = 3 ("Purge complete") and then
evaluates the Task.Delay(CompletionPause, _timeProvider, ct) that registers the
completion-pause timer. Because RunResetAsync runs off the loop, step 3 is the
signal observers gate on to know deletion finished — but it fired BEFORE the
timer it vouches for existed. On a virtualized clock (FakeTimeProvider in tests,
and any consumer advancing the injected TimeProvider) this is a lost wakeup: an
Advance that lands between "step 3 published" and "timer registered" is dropped,
the delay never fires, and the reset hangs forever awaiting a wakeup that will
never come.

Fix: create the completion-pause timer before publishing step 3, then await the
captured task. This makes "step 3 observed" a happens-before guarantee that the
pause timer already exists, so a single clock advance always fires it
deterministically. On the real clock this shifts timer registration a few
microseconds earlier; the visible "Purge complete" dwell is unchanged.

Evidence: hang-dump forensics of CI run 28676578217 (PR #1568, Netclaw.Cli.Tests
blame-hang after 300s). Test FullReset_AfterBothConfirmations_DeletesEverything
was parked at `await vm.ResetTask!.WaitAsync(ct)`; its CompleteResetAsync helper
had exhausted its advance loop (counter i == 10, all virtual-clock advances
spent) and FakeTimeProvider was left holding exactly one orphaned waiter — the
delay registered after the final Advance. Prior commits 850cf8c (#1525) and
eb01b49 (#1536) band-aided the symptom with advance/yield retry loops; this
removes the race at the source.

The test helper CompleteResetAsync is shared by all three sibling tests
(FullReset_AfterBothConfirmations_DeletesEverything,
SetupOnlyReset_DeletesConfigButKeepsMemoryAndSessions,
DaemonStopFailureResult_ShowsStatusAndContinuesReset); it now waits for step 3
then does exactly one advance, deleting the retry loop that only ever masked the
lost wakeup on loaded runners.