test: cover Election.clear pending consensus reset

[pactrover]

Summary

• add one regression test for Election.clear() resetting pending consensus state
• verify that a second transaction at the same public-key height can start after clear()
• keep the contribution test-only; production code is unchanged

Closes #406

Verification

Passed locally with Temurin OpenJDK 25.0.4.1 and Gradle 9.7.1:

• ./gradlew test --tests 'cash.atto.node.election.ElectionTest.should clear pending consensus state' --rerun-tasks --offline --no-daemon --console=plain --stacktrace --no-scan — 1 test, 0 failures
• ./gradlew test --tests 'cash.atto.node.election.ElectionTest' --rerun-tasks --offline --no-daemon --console=plain --stacktrace --no-scan — 13 tests, 0 failures

A full ./gradlew test --rerun-tasks --offline --no-daemon --console=plain --stacktrace --no-scan --fail-fast run was also attempted. It stopped in the first Cucumber bootstrap suite because Testcontainers could not find a Docker environment (/var/run/docker.sock was unavailable): 3 bootstrap feature failures and 1 skipped test. The remaining full suite was therefore not executed locally.

The focused test had previously been sensitivity-checked against a controlled copy differing only by removal of pendingConsensus.clear(); that focused run failed because transaction B did not publish ElectionStarted. This is regression-test sensitivity evidence, not a production-defect or correctness claim.

Scope

• one file changed
• 24 test lines added
• no production code, configuration, dependencies, secrets, or repository settings changed
• no live-node behavior was tested

atto://abn2pmx6dc2e43vi5zaatuhor4j6qioztqcdr2vgxivxtcw3vbgwsrztx5rtc

[rotilho]

This is pretty interesting, and I'm honestly impressed that you identified this gap and opened the issue/PR yourself. I'm happy to merge it.

That said, this isn't exactly how I usually approach testing. clear() is exercised in a very specific path, during shutdown, so a potential regression here would have fairly limited impact. This path is also already exercised by the integration tests, so it's not really 100% untested. A regression could break those tests, although a focused test like this would definitely make finding the cause easier, especially after several commits.

So I do see the value in this test and I'm happy to have it. Just keep in mind that I don't generally aim for exhaustive unit coverage. I prefer adding focused tests when the risk or likelihood of regression justifies them.

[atto-reward-bot]

Thank you for your contribution! 🎉 This PR is eligible for an contribution-tweak reward as a token of our appreciation. If you'd like to receive it, please add your address to the description of this PR. 🙏

[atto-reward-bot]

Thank you for your contribution! 🎉 This PR is eligible for an contribution-tweak reward as a token of our appreciation and will be sent to atto://abn2pmx6dc2e43vi5zaatuhor4j6qioztqcdr2vgxivxtcw3vbgwsrztx5rtc once merged. Please note that rewards are not payments but our way of saying thank you. 🙏

[atto-reward-bot]

The contribution-tweak reward was sent to atto://abn2pmx6dc2e43vi5zaatuhor4j6qioztqcdr2vgxivxtcw3vbgwsrztx5rtc in the block A321E31C10300A6FCF937E15C49274BC8867216D558B570C0F2835C20B381E80. Thank you again for your contribution!