Test Details Overview

Raise sub-5s test waits that depend on background threads (#5169)

`websocket.started_election` failed on the Windows lmdb CI job because
its 1s wait for the election to appear expired on a slow runner. The
block goes through the block processor and scheduler before an election
exists, so 1s is a tight budget under load; every other wait in that
test already uses 5s.

Survey the rest of core_test for waits under 5s and raise the ones that
sit on the same kind of background latency: block processing, cementing
and successor activation, local rep voting, real TCP delivery, wallet
actions and observer callbacks. Waits that are intentionally short stay
as they are: negative checks (`ASSERT_ALWAYS`/`ASSERT_NEVER` and the
receive activation sleep), the bandwidth limiter tests that are required
to finish under 1s, waits that are already satisfied by the time they
run, and the disabled `local_votes_cache` tests. The processing_queue
parallel test keeps proving parallelism at 5s, since serial processing
would take 32s.

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

__________

Type: commit

Hash: 44cf1faeecd287eb66b89868f2e9957f3163f25b

Created: yesterday

__________

gr0v1ty/nano-node:44cf1faeecd287eb66b89868f2e9957f3163f25b