Speed control coerces to 20–400 — below v5's max (500%); follow the engine manifest

[willwade]

Problem

The speed steppers coerce to 20–400 in both the app and IME:

• app/src/main/java/at/dasher/android/MainActivity.kt:704 — (speedPercent - 10).coerceIn(20, 400)
• MainActivity.kt:711 — (speedPercent + 10).coerceIn(20, 400)
• NativeBridge.kt:102 doc comment repeats the 20–400 contract

Dasher v5's UI allowed raw MaxBitRateTimes100 10–800 (6–500 %); users migrating from v5 (or simply fast typists) cannot reach the top of the range. The engine-side percent helper also clamped to 400 until DasherCore #55, which now derives bounds from the LP_MAX_BITRATE manifest (raw 1–1000 → ~1–625 %).

Suggested fix

• Read LP_MAX_BITRATE min/max via dasher_get_parameter_info (through the JNI bridge) and use those as the coerce bounds in the Compose UI
• Update the NativeBridge.kt:102 doc comment
• Bump the DasherCore submodule to a release containing fix(ime): re-assert output listener + always reload settings (#53 #54) #55

References

• governance RFC 0005 — Behaviour parity beyond settings
• Dasher-GTK #51 — GTK fixed the same cap (its footer was limited to 400 raw)