fix: ensure segments are below thresholds

[shuklaayush]

Replace the optimistic execution/segmentation with a checkpointing approach that checkpoints the last trace_height/instret value that is below the thresholds and use these values for the segments. This should make the segmentation more predictable for downstream usage since the segments should satisfy the thresholds (with the only caveat being if segmentation happens when there is no checkpoint to fall back to i.e. if we overshoot the threshold before the first segmentation check)

This requires storing some extra state and results in a higher segment count compared to earlier for the same thresholds. Also makes execution slightly slower since we're doing some extra work now

benchmark run with 0.7B max cells
benchmark run with 1.2B max cells

[nyunyunyunyu]

LGTM. This's more decent than subtracting DEFAULT_MAX_TRACE_HEIGHT with a random number.

[jonathanpwang]

Actual implementation is ok, but you should leave comments explaining the rational about when to use padded versus unpadded and the considerations that went into it

[github-actions]

group	app.proof_time_ms	app.cycles	app.cells_used	leaf.proof_time_ms	leaf.cycles	leaf.cells_used
verify_fibair	(+1 [+0.4%]) 269	322,610	2,058,654	-	-	-
fibonacci	(+298 [+32.6%]) 1,211	1,500,210	(+1047730 [+98.8%]) 2,107,962	-	-	-
regex	(+300 [+11.2%]) 2,972	4,108,483	(+4259282 [+31.8%]) 17,662,886	-	-	-
ecrecover	(-7 [-0.8%]) 887	140,497	2,275,056	-	-	-
pairing	(+277 [+18.6%]) 1,767	1,882,939	(+2125140 [+9.0%]) 25,847,762	-	-	-

Commit: d0480da

Benchmark Workflow