FSR V1 dashboard telemetry support

### Description Hi, I own an FSR V1 and I have been trying to get the dashboard telemetry working on it. I know you already support the FSR V2, and I understand the V1 is older, but the screen hardware is physically identical (from what i seen) — only the firmware differs. Here is what I found about my hardware: Model string: FSR, Firmware: RS21-D03-MC FW, Hardware: RS21-D03-HW FW-C, Capabilities: 01-02-01-00, Sub-devices: 0, Device type: 01-02-05-06, COM port: COM4. Here is a summary of everything i did and found. I started by adding “FSR v1” (fsr was appearing and it was controlling the leds of the wheel correctly but not the dash) as a known model in WheelModelInfo.cs with 10 RPM LEDs and 14 button LEDs, which made the plugin still correctly recognize the wheel and show the Dashboard Telemetry section in the UI. We then forced showTelemetry to true in MozaWheelSettingsControl.xaml.cs for the FSR prefix, since IsDisplayDetected never becomes true on the V1 because it has no display sub-device. After these changes, the telemetry sender starts correctly and sends over 13000 frames per session, so the communication pipeline works. i then captured the full serial communication on COM4 using Serial Port Monitor while Pit House was running and switching dashboards and sending in game telemetry on the FSR V1. From this capture i identified that the screen is controlled through device 0x15, not through a display sub-device like on the V2. i found the following key commands that Pit House sends to drive the screen: command 0x42 on device 0x15 for display initialization with different sub-commands (0x01, 0x04, 0x06, 0x0d) corresponding to dashboard switches, commands 0x40 on device 0x15 for mode configuration (sub-commands 0x0b, 0x09, 0x05), command 0x33 on device 0x15 sent with values 0x01, 0x02, 0x03, 0x00 in sequence which appears to activate dashboard pages, commands 0x3f on device 0x15 for LED color configuration, and command 0x0e on device 0x15 as a sequence counter that increments continuously, mirroring what the plugin already sends on device 0x12 for the base. i added IsFsrV1 as a property on TelemetrySender that gets set automatically when the FSR model prefix is detected. i implemented a full SendFsrV1DisplayInit method that sends the 0x42 init frame, the 0x40 mode config frames, the 0x05 command, the 0x33 sequence with all four values, and a complete LED config sequence mirroring what Pit House sends. i also added a BuildFsrV1SeqFrame method that sends 0x0e frames on device 0x15 alongside the existing sequence counter frames. i updated SendDisplayConfig to also send config frames on device 0x15 when IsFsrV1 is true. Despite all of this, the screen remains frozen on the last dashboard loaded by Pit House and does not update. The diagnostics panel consistently shows DisplayDetected as false, no configJson state received on session 0x09, and no tile-server response on session 0x03. The wheel clearly receives the frames we send since it acknowledges commands on device 0x51 (which is 0x15 nibble-swapped) and we can even see firmware debug messages like param_manage.c:340 Table written in the serial responses. But something in the protocol is still missing or wrong. I have the full serial capture available and I can test any changes you want to try since I have the hardware right here. I would be happy to share the capture file, the files I tried to edit or run any diagnostic you need. i believe you are more capable than me into making this happen. i hope what i say could help you. i have the fsr if you need tester i can help you but my coding capabilities stop there i think Thank you again for everything you do. ### Use Case fsr v1 ### Alternatives Considered _No response_ ### Hardware (if relevant) _No response_