Rate sliders hard-cap at 1000 Hz while the board advertises 22000 — users cannot select rates their hardware supports #270

The sampling-rate controls hard-code Maximum="1000" in XAML. The bench Nq1 (fw 3.7.2) advertises
22000 Hz, and both the wrapper and Daqifi.Core accept rates that high once the device has
been initialized. The UI is the only thing that cannot ask for them, so a user cannot select a rate
their hardware supports.

Measured

Read straight off the attached Nq1 over USB (/dev/cu.usbmodem1101), non-destructive — two SCPI
queries, no configuration written:

CONFigure:CAPabilities:APIVersion?  -> 2
CONFigure:CAPabilities:JSON?        -> schema_version 2
  streaming.sample_rate_range_hz    : {"min": 1, "max": 22000}
  streaming.current_max_rate_hz     : 7746
  streaming.conservative_envelope_hz: 500
  rate_model.absolute_max_hz        : 22000
  channels                          : 16 analog-input, 16 digital-io, 0 analog-output

And through the pinned Daqifi.Core 1.7.0 package against the same board, snapshotting at the two
points AbstractStreamingDevice.Connect() hydrates at:

at first ChannelsPopulated : MaxSamplingRate 1000, CapabilityDocument null
after InitializeAsync()    : MaxSamplingRate 22000, CapabilityDocument present (schema 2)
ChannelsPopulated raises   : 1

So after a completed connect, Capabilities.MaxSamplingRate on this board is 22000.
AbstractStreamingDevice.StreamingFrequency clamps to exactly that value (#255's guard), and Core
validates against the same figure — both would accept 5000 or 20000 here. The sliders stop at 1000.

Where the cap is written

Six controls, all with a literal Maximum="1000":

DevicesPanePrototype is the live desktop devices pane (MainWindow.axaml:377), not a mock.

The ceiling is a device property, not a constant

Do not replace 1000 with 22000. That would repeat the present mistake at a different value:
22000 is this board's figure, read from its capability document. Another unit, another firmware,
or a board below fw 3.5.0 (which publishes no document at all and keeps the board-table 1000) is
free to state something else. The bound must come from Capabilities.MaxSamplingRate at runtime —
the same source the wrapper's guard and Core's validator already read.

Note the ceiling also moves: it is 1000 until InitializeAsync() returns and jumps to 22000 after,
and a reconnect can re-describe it. Whatever binds the slider has to follow that, or the control
will sit at the bootstrap value for the session.

Constraint: current_max_rate_hz is enforced by nothing

Worth settling as part of this rather than after it. This board reports
current_max_rate_hz: 7746 — the rate achievable with the current channel selection — alongside
the 22000 absolute ceiling. Nothing in this app reads it: CurrentMaximumRateHz,
SampleRateCap and Core's EnforceStreamingFrequencyCap appear nowhere in
Daqifi.Avalonia/ or the test project. The wrapper clamps against the absolute ceiling only.

Today that is latent, because the UI cannot offer anything above 1000. Raising the cap to
MaxSamplingRate without also honouring the current-configuration cap would make it live: a user
could select 20000, pass the wrapper's guard and Core's validator, and have the device refuse at
start — which is the failure mode #248/#255 existed to remove, reintroduced one layer up.

Core already has the mechanism (EnforceStreamingFrequencyCap, SampleRateCap); #255 considered
and deferred adopting it. Whoever raises the cap should decide explicitly whether the slider's bound
is the absolute ceiling, the current cap, or the absolute ceiling with a warning at the current cap.

Not verified here

Whether the device actually refuses a start above current_max_rate_hz was not tested — that
needs a streaming run, and this was a read-only bench session. The claim above is that nothing in
the app enforces the figure, which is a source-level fact.

Found while shepherding #269 (which closes #257); deliberately out of scope there, since that PR is
a comment and a test file.