troubleshooting: explain the 4.1 Telemetry Lost delay

[MUSTARDTIGERFPV]

The "I am getting Telemetry Lost/Recovered" entry lists only hardware causes, all from the 3.x era: X9D/QX7 inverters, an early Happymodel Slim Pro, a 2018 ACCST R9M, a loose ES24TX enclosure, and S.Port contacts.

Since 4.1 the module deliberately delays this callout, so a user on current firmware can spend a long time hunting for a fault that is not there.

The behavior

From checkSendLinkStatsToHandset() in tx_main.cpp:

if (RxDisconnected_Ms)
{
    constexpr uint32_t LOST_NOTIFICATION_MAX_DELAY_MS = 3000U;
    // Delay a variable amount based on the LQ. Lower LQ, lower time before we tell the handset what's up
    uint32_t TelemetryLostCalloutDelay_Ms = map(constrain(linkStats.uplink_Link_quality, 50, 100), 50, 100, 0, LOST_NOTIFICATION_MAX_DELAY_MS);
    if (now - RxDisconnected_Ms > TelemetryLostCalloutDelay_Ms)
    {
        RxDisconnected_Ms = 0;
        linkStats.uplink_Link_quality = 0;
    }
}

While disconnected the TX keeps sending the last known LQ to the handset until the delay expires, then zeroes it, which is what triggers the callout. The delay is the LQ from just before the loss, constrained to 50-100, mapped onto 0-3000ms. So a healthy link has to stay down about 3 seconds before the handset is told, and a link that was already poor is reported immediately.

This is new in 4.1. git show 4.0.0:src/src/tx_main.cpp has no RxDisconnected_Ms and no delay; 4.0 zeroed the LQ at the disconnect transition with a // Notify immediately comment. git tag --contains on the introducing commit returns only 4.1.0 and 4.1.0-RC1.

The change

Adds this to the top of the section, before the hardware causes, so the reader checks the normal case first. The existing causes are unchanged.