fix(hotblocks): keep ingesting when a block time is unrepresentable

[mo4islona]

Summary

A block time outside the datetime-conversion range killed the ingest flush and left the
dataset re-requesting the same block every P-EPOCH-RETRY forever. The conversion feeds
nothing but a debug! field, so this was a log line taking the dataset down with it — and
at info level, over a line that is never emitted: the field is evaluated lazily, the
fallible conversion above it was not.

time is informational — DEF-4 says so and CN-8 forbids correctness depending on it. So
the conversion is best-effort now. What is stored is unchanged and always was the raw
Option<i64>; only the human-readable rendering could ever fail, and it degrades to None
with last_block_time_ms carrying the number, so an absurd value is still diagnosable from
the log.

Saturating conversion

self.header.timestamp * 1000 on the evm and solana paths is an unchecked i64 multiply.
With no [profile] overrides in the workspace root, dev builds run overflow-checks = true
and it panics; release wraps, and a sliver of overflowing inputs wrap back onto a
plausible-looking date. Saturating keeps an absurd input absurd. Bitcoin's timestamp: u32
cannot overflow and is untouched.

GAP-26

Closed. The register's expected behavior — "the dataset must ingest it and keep serving" —
is now what happens, so the row leaves the open register for §6.1, the way GAP-11/19/32/38
did. No regression test was written; the §6.1 entry says so and names the CT-9 scenario
(last block at time = i64::MAX).

Testing

cargo clippy and cargo +nightly fmt --check clean, with no new warnings on the changed
files. No test added — the regression test is registered against CT-9 rather than written
here. Thirty days of logs across the hotblocks-db containers carry zero occurrences of the
rejection this removes, so the path is reachable by construction rather than observed.

🤖 Generated with Claude Code