Handle BCS serialization failure gracefully in the bridge burn monitor

[ma2bd]

Motivation

Part of #147 (make sure the code handles bcs::to_bytes failures gracefully). BCS
serialization is fallible — it errors on containers nested deeper than
MAX_CONTAINER_DEPTH (500) or sequences longer than MAX_SEQUENCE_LENGTH (2³¹−1) — so
production code should not .expect() on it.

persist_cert_bytes in the bridge's Linera burn monitor serialized a
ConfirmedBlockCertificate with .expect("BCS-serialize cert"). It runs in the
long-lived burn-processor loop, so a serialization failure would panic and abort the
whole monitor task — even though the very next thing the function does (and the
certificate read in its caller) already logs and skips on error. This makes the
serialization failure path consistent with the surrounding infrastructure-error handling.

Proposal

Replace the .expect() with a match that logs a warning and returns, skipping the
height without consuming any burn's retry budget — mirroring how the caller handles a
failed certificate read.

Test Plan

CI (cargo check/cargo clippy/cargo +nightly fmt). The change is a local
error-handling swap with no behavioral change on the success path.

Release Plan

• These changes should be backported to the latest testnet branch, then
  • be released in a validator hotfix.

Links

• Relates to Make sure the code handle failures due to bcs::to_bytes gracefully #147
• Follow-up (not in this PR): ProvenEvents::new in linera-bridge/src/block_proof.rs
  still .expect()s when BCS-serializing an Event; making it fallible ripples into
  alloy::contract::Result callers, so it is left as a separate change.
• reviewer checklist