Fix stale BP rotation duplicate schedules

[TheJudii]

Summary

• Clear persisted BP/SBP rotation state whenever the active voted set has no standby range outside the top 21.
• Prevent stale rotation substitution from proposing a producer schedule with the same producer twice.
• Add a Telos system regression test for the exact 22 -> 21 active-voted-producer case.

Root Cause

A previous rotation can leave bp_currently_out and sbp_currently_in set. If the producer set later shrinks to exactly 21 active voted producers, the standby producer can move into the top 21. The old code skipped range validation when total_active_voted_prods <= TOP_PRODUCERS, so it reused the stale SBP and proposed a duplicate producer schedule.

Validation

• git diff --check HEAD~1 HEAD
• Docker workflow image configure: apm2006/leap:v3.2.5-cdt4.0.1, cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTS=yes -Dleap_DIR=/opt/leap/build/lib/cmake/leap ..
• Docker workflow image build: make -j 4 VERBOSE=1
• ctest -R telos_system_unit_test --output-on-failure passed
• ./unit_test --run_test=telos_system_tests/rotation_clears_when_standby_moves_into_top_21 --report_level=detailed passed, 84/84 assertions

Local Test Note

Full local ctest -j 4 --output-on-failure was also attempted under the amd64 Docker image on Apple Silicon. telos_system_unit_test, eosio_system_unit_test, eosio_system_limitauth_unit_test, and eosio_system_blockinfo_unit_test passed. Three unrelated suites failed at startup with the same WASM access violation: eosio_msig_unit_test, eosio_token_unit_test, and eosio_wrap_unit_test. Those failures occur outside this touched area and appear to be local emulation/container related.