Raise positive waitUntil timeouts to 5s for loaded CI runners (#1340)

NoiseCoverageTests' session-callback test failed on the first CI run
that actually executed it (every run since it landed had hung and been
killed before completion): onSessionEstablished fires via
DispatchQueue.global().async, and the test waited only 0.5s — fine on
a dev machine, too tight on a loaded CI runner saturated by parallel
test workers.

Raise every positive-wait timeout from 0.5s to 5s (matching
TestConstants.defaultTimeout) across the suites that poll for async
callbacks. waitUntil returns as soon as the condition holds, so
passing runs are unaffected; only genuine failures wait longer. The
two negative waits in BLEServiceCoreTests ("expect nothing arrives")
deliberately keep their short windows.

Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

bitchatTests/Services/TransferProgressManagerTests.swift

@@ -24,7 +24,7 @@ struct TransferProgressManagerTests {
 
         let didReceive = await TestHelpers.waitUntil({
             recorder.values == ["started:\(transferID):3"]
-        }, timeout: 0.5)
+        }, timeout: 5.0)
         #expect(didReceive)
 
         #expect(recorder.values == ["started:\(transferID):3"])
@@ -59,7 +59,7 @@ struct TransferProgressManagerTests {
 
         let didReceive = await TestHelpers.waitUntil({
             recorder.values.count == 3
-        }, timeout: 0.5)
+        }, timeout: 5.0)
         #expect(didReceive)
 
         #expect(recorder.values == [
@@ -97,7 +97,7 @@ struct TransferProgressManagerTests {
         let didReceive = await TestHelpers.waitUntil({
             recorder.values.contains("started:\(transferID):4") &&
             recorder.values.contains("cancelled:\(transferID):1:4")
-        }, timeout: 0.5)
+        }, timeout: 5.0)
         #expect(didReceive)
 
         #expect(recorder.values.contains("started:\(transferID):4"))