feat(inmotion-v1): show the real model name, write NO_RESPONSE for reliable commands

Two follow-ups now that the V8S connects reliably (MTU-wedge fix confirmed working):

1. Model name showed generic "InMotion V1 (serial)" instead of "V8S". The model
   WAS detected from the BLE name ("V8S-81E30005" -> V8S) but the display only used
   the model decoded from the slow-info bytes, which the V8S doesn't carry, so it
   fell back to the generic label. Now notifyConnectingTo emits the name-detected
   model immediately, and the slow-info path falls back to it when the bytes carry
   no model id.

2. Switch InMotion V1 writes to WRITE_TYPE_NO_RESPONSE (ATT 0x52) - the write type
   EUC World uses for all data writes. With write-with-response, an ack lagging past
   the ~250 ms poll interval gets the next write rejected code 201, which can drop a
   one-shot command like a legal-mode / speed-limit change. No-response frees the
   GATT immediately so writes never collide. Safe now that the fatal-201 cause (the
   requestMtu wedge) is fixed; the earlier NO_RESPONSE build failed on that wedge,
   not the write type.

Branch also merges origin/next-version (trip map style, studio replay panes, i18n,
dropbox conflict fix).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GADLyChheAoMX9dQbRgRnH

Author: eried

app/src/main/java/com/eried/eucplanet/ble/InMotionV1Adapter.kt

@@ -66,7 +66,11 @@ class InMotionV1Adapter @Inject constructor() : WheelAdapter {
         detectedModel = deviceName?.let { InMotionV1Model.fromReportedName(it) }
         streamStarted = false
         authPollTick = 0
-        return null
+        // Surface the model straight from the BLE name (e.g. "V8S-81E30005" ->
+        // V8S) so the UI shows the real model immediately, without waiting for -
+        // or depending on - a model id in the slow-info bytes (the V8S carries
+        // none). Returns null when the name isn't a recognised V1 model.
+        return detectedModel?.let { DecodeResult.ModelName(it.displayName, it) }
     }
 
     /**
@@ -296,10 +300,15 @@ class InMotionV1Adapter @Inject constructor() : WheelAdapter {
                 val info = InMotionV1Parser.parseSlowInfo(payload) ?: return emptyList()
                 streamStarted = true
                 if (info.model != null) detectedModel = info.model
+                // Prefer the model decoded from the slow-info bytes, but fall
+                // back to the one detected from the BLE name (V8S carries no
+                // model id in slow-info, so without this it showed as a generic
+                // "InMotion V1 (serial)" despite the name saying V8S).
+                val model = info.model ?: detectedModel
                 val out = mutableListOf<DecodeResult>()
                 out += DecodeResult.ModelName(
-                    info.model?.displayName ?: "InMotion V1 (${info.serial})",
-                    info.model
+                    model?.displayName ?: "InMotion V1 (${info.serial})",
+                    model
                 )
                 out += DecodeResult.Firmware(
                     display = "FW ${info.firmware}",

app/src/main/java/com/eried/eucplanet/ble/WheelAdapter.kt

@@ -84,14 +84,19 @@ data class BleProfile(
             // NOT the 0xFFE0 notify service. Without this the write char lookup
             // returns null on service discovery and the connect is torn down,
             // so no InMotion V1 wheel (V5 / V8 / V10 / V10F / L6) could connect.
-            writeServiceUuid = UUID.fromString("0000ffe5-0000-1000-8000-00805f9b34fb")
-            // Keep the default WRITE_TYPE_DEFAULT (write-with-response). The
-            // real cause of the code-201 write rejections was the requestMtu(512)
-            // wedging the GATT (see BleConnectionManager - MTU is now skipped for
-            // this family), NOT the write type. NO_RESPONSE was tried and the
-            // build regressed to never connecting, so it stays on the default.
-            // (EUC World does use no-response writes; that can be revisited as an
-            // isolated change once the MTU-wedge fix is confirmed.)
+            writeServiceUuid = UUID.fromString("0000ffe5-0000-1000-8000-00805f9b34fb"),
+            // NO_RESPONSE (Write Command, ATT opcode 0x52) - the write type EUC
+            // World uses for ALL its data writes. With WRITE_TYPE_DEFAULT
+            // (with-response) each write stays "busy" until the wheel acks it, and
+            // when that ack lags past the ~250 ms poll interval the next write is
+            // rejected code 201, occasionally dropping a one-shot command (e.g. a
+            // legal-mode / speed-limit change). No-response frees the GATT
+            // immediately so writes never collide. This is safe now that the real
+            // cause of the FATAL 201 storm - the requestMtu(512) wedge - is fixed
+            // (MTU is skipped for this family in BleConnectionManager); NO_RESPONSE
+            // only removes the residual collisions. The earlier NO_RESPONSE build
+            // "never connected" because of that MTU wedge, not the write type.
+            writeType = BluetoothGattCharacteristic.WRITE_TYPE_NO_RESPONSE
         )
     }
 }