fix silent crashes during cached-block catch-up sync

[ch4r10t33r]

Root cause

When syncing from a checkpoint, the node fetches a chain of blocks that
arrive out-of-order and parks them in the fetched_blocks cache.
processCachedDescendants then replays them in parent → child order.
During this burst, the node crashed silently (no log output) every few
sessions, with the last line always being:

[node] Successfully processed cached block 0x…

Why the crash was silent

All production builds use -Doptimize=ReleaseFast (Dockerfile, CI,
auto-release workflow). In ReleaseFast, Zig compiles unreachable
statements and failed bounds/overflow checks to @trap() — an illegal
instruction that kills the process immediately with no output to stdout
or stderr. Because the crash happened after the last log line was flushed,
there is no stack trace to pinpoint the exact site. The three fixes below
are defensive guards for the most likely candidates identified by code
inspection.

Fixes

1. clock.zig — unreachable on expected timer cancellation

xev fires a completion with error.Canceled when a timer is re-armed
before the previous fire is delivered. The callback was:

_ = r catch unreachable;

In ReleaseFast this compiles to an illegal instruction, killing the
process silently. Canceled is now handled explicitly and ignored;
any other error panics with a message.

2. chain.zig — out-of-bounds slice in processFinalizationAdvancement

const newly_finalized_count = finalized_roots.len - 1;  // usize underflow if 0
…
_ = self.pruneStates(finalized_roots[1..finalized_roots.len], …);  // OOB if 0

getCanonicalViewAndAnalysis can return an empty slice when the fork
choice was already rebased past the requested root (e.g. the previous
finalized checkpoint). This caused a usize underflow / OOB trap in
ReleaseFast. The fix adds an early-return guard with a warning log.

3. node.zig — missing onBlockFollowup in processCachedDescendants

processBlockByRootChunk (the normal inbound-gossip / RPC path) calls
chain.onBlockFollowup after each successful block import. This emits
head/justification/finalization events and advances
last_emitted_finalized. processCachedDescendants did not call it,
so while replaying dozens of cached blocks the finalization pointer was
never updated. When the normal path finally ran onBlockFollowup on the
next gossip block, it saw a large finalization gap and called
processFinalizationAdvancement with stale bookmarks, triggering bug 2.

The fix adds self.chain.onBlockFollowup(true, cached_block) immediately
after each successful block import, before removeFetchedBlock frees the
block memory.

Testing

• zig build — clean
• zig build test --summary all — all tests pass
• zig fmt --check . — no formatting issues

[zclawz]

Good root-cause analysis and clear description of the crash chain. The three fixes are individually correct. A few observations:

1. onBlockFollowup(true, cached_block) — signedBlock param is _ = signedBlock

The comment says "Must happen before removeFetchedBlock frees the block memory" — which implies cached_block is read inside onBlockFollowup. But the function body starts with _ = signedBlock;, meaning the pointer is never dereferenced. The ordering constraint is therefore not a memory-safety requirement today, though keeping the call before removeFetchedBlock is still good practice. Worth either removing the comment or wiring signedBlock properly if it will be used in future.

2. pruneForkchoice = true on every cached block in processCachedDescendants

processCachedDescendants is recursive (each successful import calls itself again). With onBlockFollowup(true, ...) added, processFinalizationAdvancement can now fire on each iteration if finalization advances. For a deep cached-block chain (dozens of blocks during checkpoint sync burst) this means many sequential canonical-view analyses and DB batch writes. Correct semantically, but could be slow. A possible optimization is to pass false for pruneForkchoice during catch-up and prune once at the end — but that is a follow-up concern, not a blocker.

3. Arithmetic guard in chain.zig

The if (slot_gap >= newly_finalized_count) guard is correct and safe. One minor note: if newly_finalized_count > slot_gap the orphaned count is silently zeroed rather than logged. A debug-level log here would make the edge case visible in traces, though not critical.

4. clock.zig — .disarm on Canceled

Returning .disarm is the right call — the canceled completion should not re-arm itself. The std.debug.panic for unexpected errors (rather than unreachable) is a clear improvement; at least a useful message is printed before the process exits.

Overall the root cause chain (missing onBlockFollowup → stale finalization pointer → underflow in processFinalizationAdvancement → @trap()) is well-documented and the fixes are correct. Happy to approve with the note that items 1 and 2 are worth revisiting in a follow-up.