test: stabilize WolfSSL early-loss interop case

[zRedShift]

This keeps the WolfSSL DTLS 1.3 early packet-loss interop test on the original three dropped server packets, but makes the harness ordering deterministic.

The test was calling handle_timeout(now) again immediately after delivering fresh WolfSSL client packets to the dimpl server, before draining the server output generated by that input. That can race retransmit output with the newly processed client flight and make WolfSSL fail to observe connection completion.

This changes the test to drain fresh server output before processing another timeout tick. No protocol behavior is changed.

This is not known to affect current upstream CI: the GitHub Actions matrix builds the rcgen feature, but only runs tests for aws-lc-rs and rust-crypto, so this WolfSSL interop case is mainly hit by local full rcgen validation.

It matters because cargo test --all-targets --features rcgen is the natural local "run everything" command for this repo, and this test can fail nondeterministically there even when the protocol code is unchanged.

Validation:

• cargo fmt --check
• git diff --check
• git diff --check upstream/main...HEAD
• check-snowflake-local.pl upstream/main
• cargo test --test dtls13 wolfssl::dtls13_wolfssl_server_handshake_with_early_packet_loss --features rcgen -- --exact
• 200-run loop of the exact WolfSSL early-loss test
• cargo test --all-targets --features rcgen
• cargo clippy --all-targets --features rcgen -- -D warnings
• cargo test --no-default-features --features rust-crypto
• cargo clippy --no-default-features --features rust-crypto -- -D warnings
• cargo test --doc --features rcgen

[algesten]

Nice thanks!