test: add target-discovery diagnostics on readiness timeout

[steiler]

Summary

• Targets Check Ready failures currently surface as an opaque 1 != 0 after a full 15-minute Wait Until Keyword Succeeds, with no signal on why — in particular no way to tell whether the Target CR was never created (discovery never found the device) versus created-but-not-ready.
• Adds Wait Until Target Ready in tests/Keywords/targets.robot: same wait behavior, but on timeout it dumps Target/DiscoveryRule state and api-server logs at WARN before failing with a clear message.
• Switches all 8 existing call sites (02-crud, 03-deviations) to the new keyword. No timeout/retry values changed — this is diagnostics-only, not a behavior change.

Split out of the sensitive data-server/config-server pairing (sdcio/data-server#460) investigation into recent SROS Targets Check Ready timeouts, so this can merge independently and unblock CI diagnostics for any other in-flight PR hitting the same timeout (e.g. sdcio/data-server#466).

Note: an actual discovery-mechanism change (switching sr2's DiscoveryRule from a /28 prefix scan to address-based) was tried and reverted — per project docs, unreachable-target connection errors during range scanning are expected/by-design, so that change was not the right fix. This PR only adds visibility so the next occurrence is diagnosable.

Test plan

• robot --dryrun across all 9 touched suites — 100/100 test cases pass (keyword resolution / imports valid)
• Confirm on a real CI run that the diagnostics WARN block actually surfaces useful data if Targets Check Ready times out again

Made with Cursor