fix(anvil): restore backwards compatibility for state dumps missing block/best_block_number keys

[gomesalexandre]

`SerializableState` (`crates/anvil/src/eth/backend/db.rs`) has two fields documented as "Option for backwards compatibility" that are actually hard-required by serde, while a third field with the identical doc comment correctly isn't:

```rust
/// Note: This is an Option for backwards compatibility: #5460
#[serde(deserialize_with = "deserialize_block_env_compat")] // <- missing #[serde(default)]
pub block: Option,

#[serde(deserialize_with = "deserialize_best_block_number_compat")] // <- missing #[serde(default)]
pub best_block_number: Option,

/// Note: This is an Option for backwards compatibility.
#[serde(default)] // <- has it
pub historical_states: Option,
```

serde's missing-field-defaults-to-`None` behavior only applies automatically when a field uses its own plain `Deserialize` impl. Adding `#[serde(deserialize_with = "...")]` without `#[serde(default)]` makes the field hard-required — the custom deserializer never runs if the key is absent, so you get a hard parse error instead of graceful `None`-defaulting.

Live-verified consequence

Loading an older state-dump JSON file that lacks the `block`/`best_block_number` keys entirely fails hard via both `anvil --load-state ` and the `anvil_loadState` RPC method (`error: failed to parse json file: missing field `block` at line 1 column 115`). The decisive control: the same file with the keys present-but-`null` loads fine — this is purely "absent key" vs "key present with default", nothing to do with the compat deserializers themselves.

The consumer is already written to expect `None`: `crates/anvil/src/eth/backend/mem/mod.rs`'s `load_state` does `let mut block_env = state.block.take();` then `if let Some(block) = &mut block_env { ... }`, and defaults `best_number` via `state.best_block_number.unwrap_or(...)`.

Regression origin

`#[serde(deserialize_with = "...")]` landed in #11179 ("v1.2 state load compatibility") whose explicit goal was to widen compatibility with old dump formats — but it didn't also add `#[serde(default)]`, the opposite of the PR's own intent. Pre-#11179 these fields were bare `pub block: Option` with no custom deserializer, which correctly defaulted to `None` on a missing key.

Precedent

#8501 ("`anvil_loadState` fails to decode state dump after upgrading") → #8752 ("fix(anvil): backwards compatible dumps"), merged — same bug class (an older dump file failing to load after an anvil upgrade), different field.

Why no test caught it

The closest existing test (`test_backward_compatibility_optional_fields_deserialization_v1_2`) deliberately omits three other fields to test compat, but always supplies `block` and `best_block_number` — and every `test-data/state-dump*.json` fixture carries both keys too.

Fix

Add `#[serde(default)]` to both fields, restoring the pre-#11179 graceful-degrade behavior the doc comments already claim exists.

Honest trade-off: this restores a silent partial load (rather than a loud parse error) if someone typos or truncates the `block` key in a hand-edited/corrupted dump file. This is exactly the pre-#11179 behavior, so precedent supports it as acceptable, but it's worth stating explicitly rather than presenting this as a risk-free one-word diff.

Testing

• `test_backward_compatibility_missing_block_and_best_block_number_v1_2`: direct deserialization test proving a truly-absent-key document parses to `None`/`None`, identical to the present-and-`null` control case.
• `test_load_state_missing_block_and_best_block_number_v1_2`: end-to-end test spawning a real Anvil node via `with_init_state_path` off a missing-keys dump file, verifying it boots and applies account state correctly — the real `load_state` code path, not just isolated deserialization.
• Verified real red→green: reverted just the fix, confirmed both new tests fail on unfixed code (panic on missing field), restored the fix, confirmed both pass.
• All 5 `backward_compatibility_*` tests and all 31 `state::` tests pass.
• `cargo check -p anvil --tests` clean. `cargo fmt --check` clean on stable (nightly unavailable in this environment to verify against, same disclosure as prior PRs in this campaign).
• Note: `cargo clippy -p anvil -- -D warnings` fails on a completely unmodified `master` checkout too (two pre-existing `missing_const_for_fn` findings in `mem/mod.rs`'s monad-feature shim functions, unrelated to this diff) — confirmed via `git stash` before touching anything, so not a regression introduced here.

receipts

no runtime UI change — this is a backend/RPC-level bug; the added integration test (spawning a real Anvil node off a hand-crafted missing-keys state file and verifying it boots + applies account state) is the receipt.

[github-actions]

✅ Changelog found

The deterministic check will validate the changed entry.

[figtracer]

dont need this