Log transient connect/transport failures as warnings in LogIfFailed

[harlan]

Summary

TaskUtils.LogIfFailed logs every faulted fire-and-forget task at error severity (Debug.LogException / Debug.LogError). The SDK uses it on its connect / reconnect / state-restore operations:

• ConnectUserAsync(...).LogIfFailed() (reconnect path, StreamChatLowLevelClient)
• RestoreStateLostDuringDisconnect().LogIfFailed() (StreamChatClient)
• _websocketClient.ConnectAsync(connectionUri).LogIfFailed(_logs) (StreamChatLowLevelClient)
• DisconnectAsync().LogIfFailed(_logs) (NativeWebSocketWrapper)

When the device is offline, these fail with connectivity/transport exceptions and get reported at error severity — flooding crash/error reporting (Sentry, Bugsnag, etc.) with handled, non-actionable noise. A representative production stack:

System.Net.Http.HttpRequestException: An error occurred while sending the request
 ---> System.Net.WebException: Error: SecureChannelFailure (Unable to read data from the transport connection: Network subsystem is down.)
 ---> System.IO.IOException: Unable to read data from the transport connection: Network subsystem is down.
 ---> System.Net.Sockets.SocketException: Network subsystem is down
   ...
  at StreamChat.Libs.Utils.<>c.<LogIfFailed>b__1_0 (Task)

These are expected, transient failures that the reconnect flow recovers from — they shouldn't be logged as exceptions.

Change

LogIfFailed (both overloads) now classifies the fault: connectivity/transport exceptions are logged via Debug.LogWarning, everything else stays Debug.LogException / Debug.LogError. A shared helper walks the AggregateException (flattened, plus each inner chain) for:

• System.Net.Http.HttpRequestException
• System.Net.WebException
• System.Net.Sockets.SocketException
• System.IO.IOException
• TimeoutException

Genuine (non-connectivity) failures are unaffected and still surface as exceptions.

Why this shape

This is the same rationale as #213 ("Log WebSocket connection-attempt timeout as a warning, not an exception"), applied at the LogIfFailed logger. #213 covered the WS TimeoutException inside HandleConnectionFailedAsync; this covers the REST connect/restore failures that fire-and-forget through LogIfFailed and never reach that handler.

Notes

• C# 8-compatible syntax (no or/is not patterns), fully-qualified type names so no new usings are added.
• Changelog updated under Unreleased / Fixes.

[sierpinskid]

All tests passed: