Fix Android LE Audio device type decoding

[akshatgoel07]

Summary

• preserve Android audio device type integers 26 through 35, including hidden value 28
• decode device types through explicit raw values instead of Dart enum positions
• preserve raw values when calling getStreamVolumeDb
• map the new Android types conservatively into existing cross-platform device types
• add regression coverage for decoding, invalid values, and outbound serialization

Verification that the types are missing

Verified against both released audio_session 0.2.4 and upstream master before this change:

• AndroidAudioDeviceType ends at remoteSubmix, index 25.
• Device decoding uses AndroidAudioDeviceType.values[rawType], so every value above 25 falls back to unknown.
• Searches for the Android members represented by values 26 through 35 returned no matches in either version.
• The Kotlin plugin already forwards device.type unchanged, so the loss occurs in Dart.

Android sources

• Android 14 source defines values 26 through 31, including hidden TYPE_ECHO_REFERENCE at 28.
• Android 15 source retains values 26 through 31.
• Android 16 source adds TYPE_MULTICHANNEL_GROUP at 32.
• The current Android API reference documents API 37 values 33 through 35: TYPE_BLE_HEARING_AID, TYPE_BLE_CENTRAL, and TYPE_BLE_CENTRAL_BROADCAST.

Root cause

The platform integer was treated as a Dart enum index. Explicit raw values prevent hidden or future Android constants from shifting later meanings.

Validation

• flutter test: 2 tests pass. The tests pass complete MethodChannel device maps through the real decoder for values 26 through 35, -1, 36, and null.
• The outbound getStreamVolumeDb test verifies Android value 29 is sent even though the Dart enum index differs.
• flutter analyze: no issues.
• Formatter check: no changes.

Physical LE Audio hardware was not available for verification. The attached Android 14 device reports mLeAudio: null and an active classic A2DP device, so it cannot reproduce the LE path. The regression tests verify the Dart channel boundary using the exact raw Android integers.

Scope

This changes no Kotlin code, Android permission, or manifest entry. Active-route detection and Darwin port support remain separate concerns.

Fixes #185