[Bug]: Volume Control — the output device you pick is forgotten ten seconds later

[laurentiu021]

Problem

Choosing an output device for an app in Volume Control looks like it did not work, and about ten seconds later the picker empties itself.

Two symptoms, one cause. OutputRouteUnknown drives the picker's "Choose a device" placeholder, and OnSelectedOutputDeviceChanged never clears it after a successful write:

1. The placeholder TextBlock shares its Grid cell with the ComboBox at Margin="10,0,0,0", which is where the box draws its selected item — so "Choose a device" is painted on top of the device the user just picked.
2. RefreshDevicesAsync snapshots each row as OutputRouteUnknown ? null : id before ReplaceWith. A row still flagged unknown snapshots as null and is re-applied as null, so the picker goes blank on the tenth reconcile pass. Windows keeps the route; only the UI forgets, which leaves no way to see or undo what was set.

This affects every routable app on every machine, not an edge case: the route read is still a stub that always returns null (#2088), so every row starts flagged unknown.

Steps to reproduce

1. Open Volume Control with at least one routable app playing.
2. Pick a non-default device in that app's Output picker. Note the prompt text still drawn over the name.
3. Wait ~10 seconds without leaving the tab.
4. The picker is empty again.

Expected behavior

Picking a device counts as knowing the route — SysManager is what set it. The chosen name shows alone, and it survives the ten-second device re-read. A refused write leaves the flag alone, because nothing moved.

Evidence

• SysManager/SysManager/ViewModels/AudioSessionRowViewModel.cs — OnSelectedOutputDeviceChanged
• SysManager/SysManager/ViewModels/AudioMixerViewModel.cs — RefreshDevicesAsync snapshot
• SysManager/SysManager/Views/AudioMixerView.xaml — placeholder over the ComboBox
• README already documents the intended behaviour: "the device list is re-read every ten seconds, and each app keeps the destination you picked for it"

Introduced in v1.76.7 with the three-state route flag. Before it, the snapshot read the selection directly and a hand-made pick survived.

Affected tab

Volume Control

[laurentiu021]

Fixed in v1.76.9 via #2097.

Root cause. OutputRouteUnknown had one writer — the route read — and none on the write path. A successful SetSessionOutputDevice left the row still flagged unreadable, which the picker renders as the "Choose a device" overlay and which RefreshDevicesAsync snapshots as null. The tenth reconcile pass then re-applied that null and blanked the box.

Fix. A successful write clears the flag: SysManager knows the route because it is what set it. A refused write leaves it alone, since nothing moved.

Files. ViewModels/AudioSessionRowViewModel.cs (OnSelectedOutputDeviceChanged), plus two regression tests in AudioMixerViewModelTests.

Verification. Both tests were confirmed red against the unfixed code and green after — AUserPickedDevice_IsNoLongerAnUnknownRoute on the flag itself, AUserPickedDevice_SurvivesADeviceRefresh on Expected "{hdst}", Actual null, which is the discarded choice. The two neighbouring route tests stayed green throughout, so the unknown-route contract from v1.76.7 is intact.