Flaky test: reactions::common::base::tests::test_run_standard_loop_dedup_and_checkpoint

## Summary The test `reactions::common::base::tests::test_run_standard_loop_dedup_and_checkpoint` in `lib/src/reactions/common/base.rs` is flaky when the full workspace test suite is run. ## Reproduction Running the full suite: ``` cargo test --workspace ``` produces: ``` thread 'reactions::common::base::tests::test_run_standard_loop_dedup_and_checkpoint' panicked at lib/src/reactions/common/base.rs:1115:9: assertion `left == right` failed left: [7] right: [6, 7] ``` Running the same test in isolation passes consistently: ``` cargo test -p drasi-lib --lib reactions::common::base::tests::test_run_standard_loop_dedup_and_checkpoint # test result: ok. 1 passed; 0 failed ``` ## Root cause hypothesis The test (lib/src/reactions/common/base.rs:1086-1115) enqueues query results, spawns a loop that processes events, then waits up to ~2.5s (50 × 50ms) for `handler_count >= 2`. When the test runs under heavy concurrent load (full workspace test run), the handler can race: `handler_count` reaches 2 and shutdown is signaled, but the `processed` Vec may have been read before the second push completes, or seq=6 may be deduped/dropped due to a checkpoint write race. ## Suggested fix directions - Replace the bounded poll on `handler_count` with deterministic synchronization (e.g., a channel/notify that the handler signals after each push). - Or assert on the persisted checkpoint (`cp.sequence == 7`) instead of the in-memory `processed` order, since checkpoint state is the actual contract. ## Environment - macOS (Darwin) - Rust toolchain per repo (1.83.0 in CI) - Discovered in branch `fix/add-missing-license-headers` while running `cargo test --workspace` after license-header-only edits. The failure is unrelated to those edits.