Summary

Fixes a lost-wakeup race in the "existing install" reset flow that intermittently hangs Netclaw.Cli.Tests in CI (300s blame-hang → dump). The fix is a signal-ordering change: register the completion-pause timer before publishing the step-3 "Purge complete" signal, so the signal never precedes the resource it vouches for.

This was found via hang-dump forensics on an unrelated CI failure and is independent of the PR that surfaced it (#1568) — it fixes a pre-existing race, not that PR's changes.

Root cause — signal before resource

RunResetAsync runs off the UI loop. Its old shape:

1. PublishOnLoop(... CurrentProgressStep = 3 ...) — publishes "Purge complete"
2. await Task.Delay(CompletionPause, _timeProvider, ct) — registers the completion-pause timer, then awaits it

Observers (including the test helper) gate on step 3 to know deletion finished. But step 3 was published in step (1), before the timer that (2) creates even exists. On a virtualized clock, a clock Advance that lands in the window between "step 3 published" and "timer registered" is dropped — a classic lost wakeup. The delay never fires and the reset hangs forever awaiting a wakeup that will never arrive.

Dump evidence (CI run 28676578217, PR #1568)

Netclaw.Cli.Tests blame-hung after 300s. Dump forensics:

• Test InitExistingInstallViewModelTests.FullReset_AfterBothConfirmations_DeletesEverything was parked at await vm.ResetTask!.WaitAsync(ct).
• Its CompleteResetAsync helper had spent every virtual-clock advance — loop counter i == 10 (all 10 advances exhausted).
• FakeTimeProvider was left holding exactly one registered waiter — i.e. RunResetAsync registered its Task.Delay(CompletionPause, ...) timer after the final Advance. The advance-before-registration window is precisely the lost wakeup.

The fix — happens-before, deterministic

Create the completion-pause timer first, then publish step 3, then await the captured task:

var completionPause = Task.Delay(CompletionPause, _timeProvider, ct);

PublishOnLoop(() =>
{
    CurrentProgressStep.Value = 3;   // "Purge complete" — now the timer already exists
    ...
}, ct);

try
{
    await completionPause;
}
...

Determinism argument: creating the timer first makes "step 3 observed" a happens-before guarantee that the pause timer already exists. So a single clock advance always fires it — there is no window in which an advance can be lost. On the real clock this shifts timer registration a few microseconds earlier; the visible "Purge complete" dwell is unchanged.

The shared test helper CompleteResetAsync is simplified to match the new invariant — wait for step 3, then do exactly one advance:

await WaitForProgressAsync(vm, 3);
_time.Advance(InitExistingInstallViewModel.CompletionPause);
await vm.ResetTask!.WaitAsync(TestContext.Current.CancellationToken);

The old for (i < 10) { Advance; yield } retry loop only ever masked the advance-before-registration lost wakeup on loaded CI runners; it is deleted, not retuned.

Pre-existing status

This race is pre-existing. Prior commits band-aided the symptom with advance/yield retry loops rather than fixing the ordering:

• 850cf8c (fix(tui): synchronize reset-progress ReactiveProperties to stop flaky host crash #1525)
• eb01b49 (test(tui): await reset cancellation before daemon stop release #1536)

This PR removes the race at the source, so the retry loop is no longer needed.

Coverage

All three sibling tests exercise the fixed code through the shared CompleteResetAsync path:

• FullReset_AfterBothConfirmations_DeletesEverything
• SetupOnlyReset_DeletesConfigButKeepsMemoryAndSessions
• DaemonStopFailureResult_ShowsStatusAndContinuesReset

InitExistingInstallPageTests.cs was analyzed and left untouched — it is immune (it completes via the cancellation path, not the completion-pause timer).

Validation

• Build: dotnet build src/Netclaw.Cli.Tests/Netclaw.Cli.Tests.csproj -c Release — 0 warnings, 0 errors.
• Targeted stress: affected class run 20× in Release (--filter FullyQualifiedName~InitExistingInstallViewModelTests) — 20/20 passed, none hung (15 tests each, ~100 ms/run).
• Full suite: dotnet test src/Netclaw.Cli.Tests -c Release --no-build — 1196 passed, 0 failed, 0 skipped.
• TUI smoke gate: ./scripts/smoke/run-smoke.sh init-wizard — OK (all smoke checks passed; doctor exit 2 is expected WARN-only for the temp-dir session base and absent secrets.json in the smoke sandbox).
• Slopwatch: dotnet slopwatch analyze — 0 issues found.
• Headers: scripts/Add-FileHeaders.ps1 -Verify — all files have headers.