Finalized app-shard frames dropped

[dazthecorgi]

Summary

Finalized app-shard frames can be dropped by state-dependent revalidation, potentially stalling a replica indefinitely.

Details

When an app-shard frame finalizes, handle_cw_finalized_frame re-runs full frame validation before materializing it, as a guard against a BlockStore substitution after the committee verified the proposal (app_engine.rs:2344). On any validation failure it silently drops the frame.

This revalidation can produce different results because it reads mutable local state:

• The storage-attestation check reads registered leaf roots from the local prover-registry cache (frame_validator.rs:902). That cache is cleared and rebuilt from the local persisted hypergraph. A refresh can change whether a given (member, leaf, epoch) entry exists. In particular, registration vertices retain PrevEpoch, Epoch, and NextEpoch, while the cache decoder currently loads only the main Epoch slot..
• The ρ_N derivation resolves the anchored global frame from the local clock store (frame_validator.rs:607). If the node is momentarily behind on the global chain, the anchor is "unavailable" and validation fails.

So an honest, committee-certified frame can pass validation at vote time and fail the same validation seconds later at finalize time — or pass on some replicas and fail on others.

[blacks1ne]

I opened #594 with a fix and deterministic regression coverage. It seals the exact bytes accepted at vote time, avoids state-dependent revalidation for those bytes at finalization, and preserves defensive validation for replicas that only learned the certificate without locally verifying the block.

The full quil-cw-consensus and quil-engine library suites pass in the project Docker environment, and the Linux AMD64 release node builds successfully. Colleagues, please review the trust-boundary split and the BlockStore sealing behavior.