fix(signaling): parallelize Pigeon IPC calls in _startService() to reduce FGS delay

[SERDUN]

Problem

_startService() in plugin.dart called startForegroundService() (via _hostApi.startService()) only after completing three sequential Pigeon await calls. Each await is a full Binder round-trip: Dart → BinaryMessenger → Kotlin main thread → Binder reply → Dart resumes.

Under Xiaomi HyperOS memory pressure, each round-trip adds ~100–300 ms. Three sequential calls add ~300–900 ms before startForegroundService() is even called — consuming a significant portion of Xiaomi's aggressive ~1.2s FGS promotion window.

// Before — each await blocks until Kotlin replies
await _hostApi.initializeServiceCallback(...);  // +100–300 ms
await _hostApi.saveConnectionConfig(...);        // +100–300 ms
await _hostApi.saveTrustedCertificates(...);     // +100–300 ms
await _hostApi.startService(...);                // ← startForegroundService() here

Fix

The three credential writes are independent — they write to separate SharedPreferences keys with no ordering dependency between them. They are parallelized via Future.wait(). startService() remains a separate sequential await after Future.wait() resolves, preserving the guarantee that credentials are persisted before the service starts.

// After — credential writes run concurrently
await Future.wait([
    _hostApi.initializeServiceCallback(...),
    _hostApi.saveConnectionConfig(...),
    _hostApi.saveTrustedCertificates(...),
]);
// startService() only dispatched after all credentials are written
await _hostApi.startService(...);

Result

• Removes two sequential Binder round-trips (~200–600 ms under memory pressure) before startForegroundService() is called
• startService() is explicitly sequenced after Future.wait() — no cross-channel ordering assumption
• A failure in any credential write prevents startService() from being dispatched, preserving the original error-isolation behavior

Part of

Umbrella: #1099