fix(fault): log dm-flakey guard cleanup failures instead of discarding

[overtrue]

Summary

DmFlakeyGuard::drop discarded both cleanup steps with let _ =:

if !recovery_table.is_empty() {
    let _ = self.load_table(&recovery_table, true); // restores healthy table on a REAL block device
}
let _ = self.delete_helper();                       // deletes the privileged helper pod

A silently-dropped restore leaves the injected fault table live on a real block device on the target node; a dropped delete leaks the privileged (hostPID + host-root-mounted) helper pod. Both are exactly the leak class #16 hardened — it added the logged-cleanup pattern to ChaosGuard::drop for chaos CRs, but the host/device-mapper backend (the most dangerous one, since it mutates a real block device) never received it.

This surfaces both failures via eprintln! with node/target/pod context, matching ChaosGuard::drop verbatim in style. Behaviour is otherwise unchanged — a successful cleanup path is identical; only the previously-swallowed error cases now emit an operator-visible warning.

Validation

• cargo fmt --all clean
• cargo clippy --all-targets clean
• cargo test — 236 + 15 pass, 0 failures

Follow-up to #16; part of the s3chaos review tracked in rustfs/backlog#1100.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.