Fix virtual bike target power/resistance reset to 0 when using Dircon after a brief BLE touch

Reported in #4844 (issuecomment-5090946778): with
"virtual device bluetooth" enabled on iOS, the Target Power and Target
Resistance tiles intermittently showed 0 or wrong values during a ride,
even though auto-resistance itself worked. Disabling "virtual device
bluetooth" fixed it, which pointed at the iOS BLE bridge as the culprit.

Debug log analysis (two attached rides, one with virtual_device_bluetooth
enabled and one disabled) showed the following: the client (MyWhoosh)
briefly touched the BLE lockscreen bridge once at the very start of the
ride (a single 1-byte handshake frame), then moved over to Dircon (WiFi)
for the rest of the ride, which is expected. But virtualbike::bikeProvider()
treats lastFTMSFrameReceived as a permanent latch once set - it never
resets it when Dircon takes over, so it kept calling
writeP2AD9->changePower(h->virtualbike_getPowerRequested()) every ~second
with a cached BLE-side power request that was never actually updated
again (0 for the rest of the ride, 3625/3625 occurrences in the buggy
log), overwriting the correct value that Dircon had just set moments
earlier.

Fix: reset lastFTMSFrameReceived in dirconFtmsCharacteristicChanged()
whenever a Dircon frame arrives, so the stale BLE-side latch is
invalidated as soon as Dircon proves itself the active transport for
that ride. A genuine new BLE frame will re-arm the latch normally.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: cagnulein

src/virtualdevices/virtualbike.cpp

@@ -1787,5 +1787,9 @@ void virtualbike::error(QLowEnergyController::Error newError) {
 void virtualbike::dirconFtmsCharacteristicChanged(const QLowEnergyCharacteristic &characteristic,
                                                   const QByteArray &newValue) {
     lastDirconFTMSFrameReceived = QDateTime::currentMSecsSinceEpoch();
+    // Dircon is now the active transport for this ride: invalidate the BLE latch so the
+    // iOS lockscreen bridge in bikeProvider() stops re-pushing its stale cached power/slope
+    // request (e.g. from a single early BLE handshake byte) on top of the correct Dircon value.
+    lastFTMSFrameReceived = 0;
     qDebug() << QStringLiteral("lastDirconFTMSFrameReceived") << lastDirconFTMSFrameReceived;
 }