Fix flaky libp2p-kad bootstrap timing test

PR #6418 hit a libp2p-kad CI failure in an unrelated change set. The failure looks like a flaky real-time bound in a Kad bootstrap test, and it can block PRs that do not touch Kad.

Failed CI:

• PR: https://github.com/libp2p/rust-libp2p/pull/6418
• Head commit: 6d76360af4c7d9978aa11fa954d264b57a7d8ae7
• Workflow run: https://github.com/libp2p/rust-libp2p/actions/runs/25371437253
• Failed job: Test libp2p-kad
• Job URL: https://github.com/libp2p/rust-libp2p/actions/runs/25371437253/job/74395720743

The failing test was:

bootstrap::tests::given_periodic_bootstrap_when_routing_table_updated_then_wont_bootstrap_until_next_interval

The job log shows:

thread 'bootstrap::tests::given_periodic_bootstrap_when_routing_table_updated_then_wont_bootstrap_until_next_interval' panicked at protocols/kad/src/bootstrap.rs:275:9:
assertion failed: elapsed < MS_5 * 2

test result: FAILED. 72 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 75.93s

The assertion is checking that a bootstrap scheduled with MS_5 completes in less than MS_5 * 2, so the test depends on a 10 ms wall-clock bound:

const MS_5: Duration = Duration::from_millis(5);

let start = Instant::now();
await_and_do_bootstrap(&mut status).await;
let elapsed = Instant::now().duration_since(start);

assert!(elapsed < MS_5 * 2);

Why this looks unrelated to PR #6418:

• The PR branch did not change protocols/kad.
• The changed files were limited to dependency metadata, libp2p-dns, libp2p-mdns, libp2p-tls, the top-level builder DNS wiring, and changelogs.
• The libp2p-kad dependency tree for normal/dev edges does not go through Hickory, DNS, or mDNS.
• The exact failing test passed locally once while investigating, and then passed five more times in a loop.

Suggested fix:

Make the test deterministic instead of asserting that a 5 ms timer completes within a 10 ms real-time budget on a shared CI runner. For example, use Tokio's paused time support if it fits this module, or relax/restructure the assertion so scheduler delay does not fail the test when the behavior is otherwise correct.

Start in protocols/kad/src/bootstrap.rs at bootstrap::tests::given_periodic_bootstrap_when_routing_table_updated_then_wont_bootstrap_until_next_interval and inspect the elapsed-time assertion around MS_5. Run this targeted test, then make its timing check deterministic or independent of scheduler delay. Confirm the test passes reliably on repeated runs.