Stabilize ProviderIdQueue drain-timeout fuzz test under full-suite load

[tabmail-kmyi]

Why

ProviderIdQueueFuzzTests.drainTimeoutIsDistinctAndTeardownSafe() can fail when the entire iOS test suite runs under load, while the exact fuzz suite passes when rerun alone. This creates noisy full-suite failures and can obscure real regressions.

Observed behavior

• Two consecutive full-suite runs reached 9,358 tests and failed only this test (plus one separately known issue).
• An immediate isolated rerun of ProviderIdQueueFuzzTests passed all 6 tests.
• The failing assertion concerned teardown state remaining live after the drain timeout path.

Expected behavior

The fuzz test should deterministically await or clean up every session it creates, regardless of full-suite scheduling pressure.

Suggested scope

• First determine whether the timeout/teardown race is confined to the test harness.
• Stabilize the test with explicit lifecycle synchronization rather than longer arbitrary sleeps.
• Only change production queue behavior if a production-reachable lifecycle defect is independently demonstrated.

Priority

Low. The failure is reproducible only under the full-suite load so far, and the exact suite passes in isolation. It should not block unrelated feature PRs, but it should be fixed so the full suite returns a reliable signal.

[tabmail-kmyi]

Re-triaged under the new P0–P5 priority scheme (2026-09-04): P3 → P5 — test-harness flake; chore.

[tabmail-kmyi]

Resolved by #105 (commit 615670a), which waits for the fake IMAP server to observe transport closure before asserting teardown, while retaining the bounded failure and abandoned-session checks. The fix remains on main. The named drainTimeoutIsDistinctAndTeardownSafe regression also passed in the final full native suite for #132: 9,618 declarations, one unchanged expected failure, zero unexpected failures or skips.