wevibe-chorus-pro.md

WeVibe Chorus Pro: tested protocol for three independent motors

I've reverse-engineered and tested support for the WeVibe Chorus Pro, and would be
grateful if someone could upstream it. A ready-to-apply diff against current master is
attached (chorus-pro.diff: protocol, device config, and a test case; the generated
config JSON and version.yaml are left out to be regenerated).

Device
- BLE name "Chorus Pro", same service/characteristics as the existing wevibe-chorus
  protocol (service f000bb03-0451-4000-b000-000000000000, tx f000c000-..., rx f000b000-...).
- Three vibrators: one in the internal arm, and two in the external arm (tip and base).

Protocol (captured from the We-Connect Android app with an HCI snoop log, then verified
by driving the toy directly)
- The app never uses the 0x0f command on this device. It uses a 16-byte command:
    e0 M1 M2 M3 00 00 00 00 00 P1 P2 P3 00 00 00 00
  M1 = external tip, M2 = internal, M3 = external base, speeds 0-30.
  P1-P3 are per-motor pattern bytes: 0x03 = steady, 0xaa = off, 0xff = keep current
  pattern; other values select built-in patterns (0xad, 0xab, 0x07/0x06 staggered).
- No init sequence is needed.

Why not 0x0f on the Pro
- Each 0x0f packet is stored by the toy as its stand-alone configuration: the status
  byte becomes a persistent enabled-motor mask (Readback byte 11) and the speeds become
  stored levels. If a session ends on a low or partial setting (e.g. device_tester
  killed during its 5% step), the toy keeps only one motor enabled at a very low level
  and seems dead until something writes mask 0x07 again.
- 0xe0 never changes that mask. Levels it stores are the same as normal app use.

Tested on real hardware
- Each slot drives the expected motor independently.
- Level 1 is perceptible; 30 is full.
- Resending pattern 0x03 on every speed change gives smooth ramps.
- Stopping (speeds 0, patterns 0xaa) works per motor.
- The toy keeps running after a BLE disconnect without a stop (no built-in timeout).
- Killing device_tester mid-sweep with this change leaves the toy working normally.

The change
- wevibe_chorus.rs: devices with three vibrate features (the Pro) send 0xe0 with
  pattern 0x03 for running motors and 0xaa for stopped ones; the two-motor Chorus keeps
  the existing 0x0f behaviour byte-for-byte.
- wevibe-chorus.yml: "Chorus Pro" name and a configuration with three vibrate features
  (0-30), in the same feature order as the two-motor Chorus: 0 = internal (M2),
  1 = external tip (M1), plus 2 = external base (M3).
- New test_wevibe_chorus_pro.yaml, registered alongside the Chorus test (and excluded
  from the v0 runs, like the Chorus).
- All WeVibe protocol tests pass.