Site Explorer treats a BMC reset's timestamp-write failure as a reset failure

[chet]

What

In crates/site-explorer/src/lib.rs, redfish_reset_bmc and ipmitool_reset_bmc perform the physical BMC reset and then persist a rate-limit timestamp (set_last_redfish_bmc_reset / set_last_ipmitool_bmc_reset) in the same function, propagating the timestamp transaction's error with ?. So when a reset physically succeeds but its timestamp write fails (txn_begin, set_last_*, or commit), the function returns Err, which causes two problems:

1. Miscount: record_bmc_reset_outcome logs it as a failed reset and does not increment carbide_site_explorer_bmc_reset_count, even though the reset happened.
2. Redundant reset: on the Redfish path the dispatch's && short-circuits on the false return, so it falls through and issues a second reset via IPMI — the BMC is reset twice for one intended reset.

Why now

Pre-existing behavior (the ?-propagation of the timestamp write and the Redfish→IPMI fall-through both predate #3179, which only changed how the outcome is counted). Surfaced by CodeRabbit during the review of #3469.

Fix direction

Separate the physical-reset result from the timestamp bookkeeping: a successful physical reset should count as a success and stop the dispatch (no fall-through) even if the timestamp write fails, and the timestamp failure should surface as its own warning rather than masquerading as a reset failure.

Code touched by #3179; surfaced in #3469.