network_monitor: `parse_ping_stdout` mishandles a 100%-packet-loss ping response

[chet]

Summary

parse_ping_stdout in crates/agent/src/network_monitor.rs assumes the last line of ping output is always the RTT summary (rtt min/avg/max/mdev = …). When a host is fully unreachable, ping reports 100% packet loss and emits no RTT line at all — so the function misreads the packet-statistics line as the RTT line, then fails to parse success_count, instead of correctly reporting zero successes.

Where

crates/agent/src/network_monitor.rs, parse_ping_stdout:

let mut lines_iter = stdout.lines().rev();
let rtt_line = lines_iter.next()...;      // assumes the last line == RTT line
let summary_line = lines_iter.next()...;  // assumes 2nd-to-last == summary

On a 100%-loss response the last line is the summary, so summary_line points at the wrong line and success_count parsing errors out.

Expected

A 100%-packet-loss response should return DpuPingResult { success_count: 0, average_latency: None }, not an error.

Suggested fix

Stop relying on line position. Find the summary line by regex first (it's always present), parse success_count, return the zero-success result immediately when it's 0, and only look for / require the RTT line when success_count > 0.

Notes

Surfaced by CodeRabbit while reviewing PR #3566 (the error-message casing sweep). It isn't casing-related, so it's filed separately here. A unit test that feeds a 100%-loss ping transcript would pin the fix.

[shouryasrivastava]

I would like to work on this. I will update the parser to locate the packet-summary line independently, handle zero successful packets without requiring an RTT line, and add a regression test for a 100%-packet-loss transcript.