Fix crash from unhandled exceptions in RspConnector

[xusheng6]

Summary

• Replace all throw std::runtime_error(...) in RspConnector::ExpectAck, TransmitAndReceive, and GetXml with LogError(...) + return empty/default values
• These exceptions were unhandled in the call stacks of CorelliumAdapter::Connect, GdbAdapter::Connect, and EsrevenAdapter::Connect, causing crashes (aborts)
• Callers already handle empty responses gracefully (e.g., LoadRegisterInfo returns false on parse failure, which is already checked)

Test plan

• Connect to a GDB remote that returns malformed RSP data — verify error is logged and connect fails gracefully instead of crashing
• Connect to a Corellium target — verify normal operation is unaffected
• Disconnect during RSP handshake — verify no crash

Fixes #1043

🤖 Generated with Claude Code

[plafosse]

You changed from throw to return empty but it doesn't look like you're handling that return empty anywhere? Changing RspConnector::ExpectAck() from “throw on protocol failure” to “log and return empty” is not safe for the resume paths that ignore its return value. GdbAdapter::GenericGo, CorelliumAdapter::GenericGo, and EsrevenAdapter::GenericGo all set their local running flag, send the packet, call ExpectAck(), and then continue into ResponseHandler(...) without checking whether the ack failed (public/debugger/core/adapters/gdbadapter.cpp:1052, public/debugger/core/adapters/corelliumadapter.cpp:918, public/debugger/core/adapters/esrevenadapter.cpp:1903). With this PR, a disconnect or malformed ack no longer aborts that flow; it just logs and keeps going. That can leave the adapter/controller believing the target resumed when the command was never successfully acknowledged, which is a behavioral regression from the previous fail-fast behavior.

[plafosse]

that same commit again

[xusheng6]

You changed from throw to return empty but it doesn't look like you're handling that return empty anywhere? Changing RspConnector::ExpectAck() from “throw on protocol failure” to “log and return empty” is not safe for the resume paths that ignore its return value. GdbAdapter::GenericGo, CorelliumAdapter::GenericGo, and EsrevenAdapter::GenericGo all set their local running flag, send the packet, call ExpectAck(), and then continue into ResponseHandler(...) without checking whether the ack failed (public/debugger/core/adapters/gdbadapter.cpp:1052, public/debugger/core/adapters/corelliumadapter.cpp:918, public/debugger/core/adapters/esrevenadapter.cpp:1903). With this PR, a disconnect or malformed ack no longer aborts that flow; it just logs and keeps going. That can leave the adapter/controller believing the target resumed when the command was never successfully acknowledged, which is a behavioral regression from the previous fail-fast behavior.

I changed it so that ExpectAck() now returns a bool, and the callers all check its return value.

Also, When ExpectAck fails, we are using LogError to display an error dialog so that the user knows what is going on

[plafosse]

I'm not seeing these changes but that sounds like the appropriate thing to do.