[Feature Request] Do not log a stack trace at WARN level when an MQTT connection is lost

# Context

* **OS and version used:** Ubuntu 26.04
* **Java runtime used:** OpenJDK version "17.0.19" 2026-04-21
* **SDK version used:** 2.5.1
* **Protocol used:** MQTT over WebSockets

Whenever an MQTT connection is lost, the SDK changes the transport status to `DISCONNECTED_RETRYING` with reason `NO_NETWORK` and logs the event at `WARN` level.

The warning includes the complete stack trace of the associated `ProtocolException`. This happens every time the MQTT connection is lost.

When a device experiences frequent connection interruptions, the same stack trace is logged repeatedly. This can generate a large volume of logs in a short period, even though the SDK is handling the interruption through its normal reconnection mechanism.

For example, the following sequence is repeated for every disconnection:

```text
2026-08-16T03:06:28,025 | INFO | ---azure-iot-sdk-IotHubReconnectTask | IotHubTransport | - - | Updating transport status to new status CONNECTED with reason CONNECTION_OK

2026-08-16T03:06:29,546 | WARN | MQTT Rec: | IotHubTransport | - - | Updating transport status to new status DISCONNECTED_RETRYING with reason NO_NETWORK
com.microsoft.azure.sdk.iot.device.transport.ProtocolException: Mqtt connection lost
at com.microsoft.azure.sdk.iot.device.transport.mqtt.exceptions.PahoExceptionTranslator.convertToMqttException(PahoExceptionTranslator.java:63)
at com.microsoft.azure.sdk.iot.device.transport.mqtt.Mqtt.connectionLost(Mqtt.java:335)
at org.eclipse.paho.client.mqttv3.internal.CommsCallback.connectionLost(CommsCallback.java:304)
at org.eclipse.paho.client.mqttv3.internal.ClientComms.shutdownConnection(ClientComms.java:441)
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:197)
at java.lang.Thread.run(Unknown Source)
Caused by: org.eclipse.paho.client.mqttv3.MqttException: Connection lost
... 2 more
Caused by: java.io.EOFException
at java.io.DataInputStream.readUnsignedByte(Unknown Source)
at java.io.DataInputStream.readByte(Unknown Source)
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92)
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137)
... 1 more

2026-08-16T03:06:29,734 | INFO | ---azure-iot-sdk-IotHubReconnectTask | IotHubTransport | - - | Updating transport status to new status CONNECTED with reason CONNECTION_OK
```

I believe that the whole stacktrace would not be necessary here. Perhaps just the message of the exception and/or the message of the cause would suffice:

```text
2026-08-16T03:06:29,546 | WARN | MQTT Rec: | IotHubTransport | - - | Updating transport status to new status DISCONNECTED_RETRYING with reason NO_NETWORK: Mqtt connection lost (cause: Connection lost)
2026-08-16T03:06:29,734 | INFO | ---azure-iot-sdk-IotHubReconnectTask | IotHubTransport | - - | Updating transport status to new status CONNECTED with reason CONNECTION_OK
```

Thank you very much for your support.

Start with Mqtt.connectionLost and PahoExceptionTranslator.convertToMqttException, then trace where the DISCONNECTED_RETRYING status is logged at WARN level. Check how the ProtocolException is passed to that log call. Done means repeated MQTT connection losses still report the status and useful exception message without logging the complete stack trace.

Written by the indexing model from the issue text.