CLI default streaming path bypasses Core's validated StreamingFrequency setter (accepts out-of-range --rate)

[tylerkron]

Summary

The CLI's default streaming path sends the raw SCPI start command with the unvalidated rate, bypassing Core's validated StreamingFrequency setter added in daqifi-core#349 (#336). As a result --rate 50000 (or 0) is accepted and streamed to the device with no client-side guard.

Evidence (Nq1, FW 3.7.2, core main)

$ dotnet Daqifi.Core.Cli.dll --serial <port> --rate 50000 --duration 2 --channels 1
Connected...
Streaming at 50000 Hz...      <-- accepted, no rejection
Streaming stopped.

By contrast the --sd-log-start path does use the validated setter and correctly rejects it:

$ dotnet Daqifi.Core.Cli.dll --serial <port> --sd-log-start --rate 50000 ...
Error: ArgumentOutOfRangeException: Streaming frequency must be between 1 and 1000 Hz ...

Root cause

Program.cs:297 (and :1301) do:

device.Send(ScpiMessageProducer.StartStreaming(options.SampleRate));
Console.WriteLine($"Streaming at {options.SampleRate} Hz...");

i.e. the raw producer, not streamingDevice.StreamingFrequency = options.SampleRate (used at :881 on the SD-log path).

Why it matters

The example app is the consumer reference. Demonstrating the raw path teaches consumers to bypass the validation Core just added. It also means the two streaming paths behave inconsistently for the same --rate.

Suggested fix

Set streamingDevice.StreamingFrequency = options.SampleRate before starting (letting the ArgumentOutOfRangeException surface as a clean CLI error), on both the live-stream and any other start paths, so --rate is validated uniformly.

Found during an autonomous live-hardware testing pass.