persist: harden state diffs, part stats and spine fuel against malformed input

[def-]

Three unchecked-arithmetic and unchecked-decode fixes in mz-persist-client.
Each one is on a path that reads durable state, where the bytes are whatever
consensus or blob happened to hold, so none of the inputs are trusted.

• ProtoStateFieldDiffs::validate summed data_lens with unchecked
  arithmetic. Overflow checks are off in the release and optimized profiles,
  so data_lens = [u64::MAX, 1] with empty data_bytes wrapped the sum to 0,
  matched the real byte length, passed validation, and left the iterator
  slicing 0..u64::MAX out of an empty slice. Sums with checked_add now and
  rejects on overflow, so a malformed diff becomes the same decode error as
  every other inconsistency validate catches.

• LazyPartStats's Debug panicked on a malformed encoding. The proto is
  held undecoded and stored without validation, and Debug called a
  decode() that expects it to be well formed. That is reachable on the
  state-load rejection path: Spine::validate formats the spine into the
  message it rejects with, so a rollup whose trace fails validation and
  carries malformed part stats panicked while building the error meant to
  reject it. The shard then failed to load by panic rather than by error, on
  every attempt. Splits out try_decode and renders an <undecodable: ...>
  placeholder instead.

• The spine's fuel computation could wrap. (8 << batch_index) * effort
  was unchecked in both steps, with batch_index derived from the inserted
  batch's len. Saturates now.

One NOTE: is left in the code deliberately: the read-path callers of
LazyPartStats::decode() (fetch.rs, filter pushdown in
operators/shard_source.rs) run on the same untrusted bytes and still panic on
a malformed encoding. Each needs its own decision about what a missing-stats
fallback should do, so they are out of scope here.

Tests

Adds proto_state_diff_data_lens_overflow_is_error and
lazy_part_stats_debug_does_not_panic_on_garbage, both of which panic without
the corresponding fix, plus coverage for the saturating fuel computation. The
LazyPartStats panic was found by the rollup_proto_roundtrip cargo-fuzz
target in release-qualification 1330 (v26.35.0-rc.1). That target is sharpened
in #37979, which should land after this.