feat: Deferred block proving

[sergerad]

Context

We are adding deferred (asynchronous) block proving for the node, as described #1592. Currently, block proving happens synchronously during apply_block, which means block commitment is blocked until the proof is generated.

Blocks will now exhibit committed (not yet proven) and proven states. A committed block is already part of the canonical chain and fully usable. Clients that require proof-level finality can opt into it via the new finality parameter on SyncChainMmr.

Changes

• Schema: Added proving_inputs BLOB and is_proven BOOLEAN columns to the block_headers table, with partial index for querying proven (is_proven = 1) blocks.
• Block proof file storage: Block proofs are stored as files via BlockStore (following the existing block file pattern) rather than as BLOBs in SQLite. The DB tracks only an is_proven flag.
• DB queries: Added mark_block_proven, select_block_proving_inputs (returns deserialized BlockProofRequest), and select_latest_proven_block_num.
• Decoupled proving from apply_block: The BlockProofRequest is now serialized and persisted alongside the block during apply_block.
• Proof scheduler: Added a background task (proof_scheduler.rs) that drives deferred proving. It queries unproven blocks on startup (restart recovery), listens for new block commits via Notify, and proves blocks concurrently using FuturesOrdered for FIFO completion ordering. Proofs are saved to files, then the block is marked proven in the DB.
• Finality on SyncChainMmr: Added a Finality enum (COMMITTED, PROVEN) to the protobuf and a finality field on SyncChainMmrRequest.
• Refactored apply_block query: Introduced ApplyBlockData struct to replace the 7-parameter function signature.

[Mirko-von-Leipzig]

Looking quite good! I think we can simplify the loop