chore(coordinator): scaffold ConflationAppV2 for RISC-V cutover

[gauravahuja]

#3086

Summary

• Adds ConflationAppV2, the RISC-V conflation app that monitors L2 blocks from the cutover timestamp onward.
• ConflationAppV1 is updated to stop at min(riscvStartingBlockTimestampInclusive - 1s, forceStopConflationAtBlockTimestampInclusive) so V1 and V2 hand off cleanly.
• ConflationAppV2 is wired into CoordinatorApp and only instantiated when riscvStartingBlockTimestampInclusive is configured.

Design

Starting point resolution (resolveStartingPoint): on start(), V2 fetches max(lastFinalizedBlock, lastRiscVConflatedBlock) and checks its timestamp against the cutover:

• Timestamp < cutover → ByTimestampInclusive(cutover) — cold start, polls until L2 reaches cutover then binary-searches for the exact first block
• Timestamp ≥ cutover → ByBlockNumberExclusive(candidateBlock) — restart, resumes from last known block

Stubs (to be replaced):

• getLastRiscVConflatedBlock() returns null — wired to RISC-V execution proof repository once implemented
• blockCreationListener logs the block number — wired to ExecutionProofGeneratingCoordinator once the pipeline is ready

Internal dependencies (not constructor params):

• lastProvenBlockNumberProvider — BatchesRepoBasedLastProvenBlockNumberProvider, same as V1
• targetCheckpointPauseController — no-op (V2 has no checkpoint pausing)

---

Note

Medium Risk
Changes conflation lifecycle and V1 stop boundaries at a hard-fork cutover; misconfiguration could affect where V1 stops, though V2 does not yet process proofs.

Overview
Introduces ConflationAppV2, a scaffold that watches L2 blocks from the RISC-V cutover onward and will feed the RISC-V execution proof pipeline. It is created only when riscvStartingBlockTimestampInclusive is set and is started/stopped alongside V1 in CoordinatorApp.

ConflationAppV1 is adjusted for a clean handoff: it requires the cutover timestamp to appear in timestampBasedHardForks, and its block monitor’s lastL2BlockTimestampToProcessInclusive becomes the minimum of the cutover timestamp and any existing force-stop timestamp so V1 can seal its last batch at the cutover block.

V2 resolves a BlockCreationMonitor starting point on startup (wait for cutover vs resume by block number). Proof progress and real conflation are stubbed—the listener only logs blocks and getLastRiscVConflatedBlock() always returns null until later work lands.

^{Reviewed by Cursor Bugbot for commit 3d14b48. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 0% with 77 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...neth/coordinator/app/conflation/ConflationAppV2.kt	0.00%	63 Missing ⚠️
...in/kotlin/lineth/coordinator/app/CoordinatorApp.kt	0.00%	10 Missing ⚠️
...neth/coordinator/app/conflation/ConflationAppV1.kt	0.00%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 3d14b48. Configure here.}

[cursor]

Cold start skips cutover blocks

High Severity

When getLastRiscVConflatedBlock() is null but lastFinalizedBlock already has timestamp ≥ cutover, resolveStartingPoint chooses ByBlockNumberExclusive(lastFinalizedBlock) and treats it as a resume. That skips every block from the cutover through lastFinalizedBlock, so a true RISC-V cold start after L1 has moved past the cutover never processes those blocks.

 

^{Triggered by project rule: Bugbot Review Instructions}

^{Reviewed by Cursor Bugbot for commit 3d14b48. Configure here.}