I understand the frustration. I am using 1.5.2 on my customers Boron
gateway to Xenon mesh network. With some proactive code to monitor the condition of the current Particle cloud connection on all my devices I am able to avoid (so far) long term lockouts from the cloud when a device goes offline. This solution ain't perfect. 
(Please, from anyone, I need no further reminders of the deprecation of the mesh firmware. 
)
I am occasionally reseting devices or forcing a new session (Handshake) even though there is an apparent cloud connection. To do this, I am using the library DiagnosticsHelperRK to look at the condition of the present cloud connection. Here are some statements I use:
g_status = DiagnosticsHelper::getValue(DIAG_ID_CLOUD_CONNECTION_STATUS);
// **connected** = 2 connecting = ??????
g_errorCode = DiagnosticsHelper::getValue(DIAG_ID_CLOUD_CONNECTION_ERROR_CODE);
// error code = 0 (**no error**) 10(?????) 17(?????)
g_status should be "2" AND g_errorCode should be "0" for a good connection.
If the above status OR error code change and persist for a few minutes then I take action rather than wait for disconnection from the cloud server.
You are probably already using keepAlive() (in some form) and sending a ping periodically using Particle.publish(). When status or error code go bad, it may be these "pings" are not acknowledged by the cloud because they are not sent or heard. In this case, the apparent comm line might be disconnected and the device made offline after some timeout period.