Slow the session list down, and stop hiding the sample rate until Start

[revtex]

Three faults on the Record page, reported together.

The session list scrolled three tracks per notch

RecordSavedList scrolled by item. Its rows are two lines tall, so one wheel notch moved about 150 DIP — three finished tracks at once, with no way to move through the list slowly.

MetadataTrackList was built with VirtualizingPanel.ScrollUnit="Pixel" and never had the problem. The session list simply never got the same line. One line, with a precedent in the same repo.

The sample rate appeared only once recording started

MP3 320K 48K showed its first two parts while idle and grew the third on Start, which reads as the display filling in rather than as the deliberate omission it was.

The reason recorded for it was wrong. The remark said the capture endpoint's rate "is not knowable until the endpoint is open" — but the rate is a property of the endpoint, and MMDevice reports its mix format at any time. It is also the same endpoint capture opens: LoopbackAudioCapture resolves the identical id through AudioEndpoints.Resolve and takes its format from the device, so the idle figure is the one the recording will use, not a guess.

A device that cannot be read still prints nothing rather than a placeholder — a wrong number on the line that claims to describe the file is worse than a short one.

Verified against a running build: an idle window's RecordFormat element now reads MP3 320K 48K, where it previously read MP3 320K.

The display ignored settings changed while idle

Fixing the above exposed this. FormatSummary always read settings fresh, but Sync() runs only at construction, on start and on stop — so changing the format, the bitrate or the capture device while idle left the page describing the file the previous settings would have produced, until something was recorded.

The controller now listens to SettingsDocument.Changed and raises OutputChanged. That is deliberately not StateChanged, which promises to mean "IsRunning changed" and would stop meaning it if settings borrowed it. Disposal unsubscribes.

Verification

• .\build.ps1 -Test — 1,272 pass, 0 fail (265 UI + 1,007 Core), 0 warnings.
• .\build.ps1 -VerifyFormat — clean.
• Three new tests: the format line follows a bitrate changed while idle, OutputChanged fires on save, and disposal stops it firing.

The sample-rate read itself is not unit-tested — it crosses into WASAPI through AudioEndpoints.Resolve, and the existing tests deliberately keep the controller away from real devices. It is covered by the try/catch and checked against a live window instead; the assertions above use StartsWith so they pass on a machine with no audio endpoint at all.