Summary

Fixes the flaky InitExistingInstallViewModelTests.ResetFailure_ShowsErrorAndDoesNotNavigate test-host crash introduced by #1514 ("#1494 stop daemon before reset").

Root cause

#1494 moved the install reset onto a background Task.Run thread that publishes progress by writing four ReactiveProperty instances — StatusMessage, CurrentProgressStep, ProgressMessage, CanQuitProgress.

• In production the view model is bound to the Termina render loop, so PublishOnLoop marshals every write onto the single loop thread — single-threaded, safe.
• In a unit test the view model is never bound, so ReactiveViewModel's default InvokeAsync runs the write inline on the background thread, while the test thread concurrently Subscribes/disposes the same property in the WaitFor* helpers.

R3's ReactiveProperty<T> is not thread-safe: its value-set path walks the observer linked list lock-free, while Subscribe/Dispose mutate that list under lock(this). The two race and can corrupt the list into a cycle → the value-set walk never terminates → the reset Task never completes → the xunit host is killed by the watchdog. That matches every symptom: flaky, Ubuntu-only on a given run, no managed stack trace, and the same commit observed both green and red. (ThrowUnobservedTaskExceptions is off, confirming it's the hang-cycle, not an unobserved fault.)

Diagnosed against the dotnet-skills:r3-reactive-extensions concurrency contract: "OnNext must not be called concurrently/re-entrantly from multiple threads … or use SynchronizedReactiveProperty."

Fix

Make the four properties written from the background thread SynchronizedReactiveProperty<T> (R3's built-in lock-based variant — serializes set/subscribe/dispose on one monitor; uncontended in production). The declared type stays ReactiveProperty<T>, so InitExistingInstallPage and every reader is unchanged. CurrentPhase/SelectedIndex are input-thread-only and left as plain ReactiveProperty.

Verification

• Builds clean; all 16 InitExistingInstall tests pass, including the formerly-flaky ResetFailure case across repeated runs.
• Slopwatch: 0 issues; copyright headers present.
• The race only surfaced on specific CI hardware — hundreds of local iterations (incl. heavy contention) didn't reproduce — so CI over time is the real proof. The change is a minimal, root-cause fix that reuses an existing R3 type.