CDS Backend Edge Cases

Injecting into real hardware, via a `CDS` backend, introduces a number of additional edges cases that need to be addressed. Many of these are oriented towards production versions, with a larger user base, but planning for them sooner is beneficial.

Also feel free to spin out any identified edge case into its own issue, and then link it to this issue.

## Preliminarily Identified
- [ ] Injection test point/s cleared by another user/process.
- [ ] Readback test point/s cleared by another user/process.
- [ ] Framebuilder reboots interrupting the availability of data and ability to inject excitation/s.
- [ ] (Suspension) Watchdog/s trips - preventing the excitation from reaching the hardware for safety reasons.
- [ ] Large/NaN/data stream underflow occurs in the excitation/s.
- [ ] User/s nominate invalid channel name/s for injection, includes slow EPICS channels which are readback only.
- [ ] User/s nominate invalid channel name/s for readback.
- [ ] Test point/s timeout.
- [ ] A CDS timing issue occurs. This can also affect communication between workstations (deployment machines) and the framebuilder (portal to the real time CDS and machines running the control algorithms).
- [ ] A network issue occurs.

## Other Issues

Comment below, also includes providing more context about a specific issue above.

No files or tests are named. Start by tracing the CDS backend's hardware injection and readback flows, then review each listed edge case, including invalid channels, timeouts, watchdogs, data underflow, timing, and network failures. Done means the cases are addressed or split into linked issues with clear scope.

Written by the indexing model from the issue text.