Crash in AudioStreamAAudio::read

Android version(s): 9 to 14
Android device(s): several (see below)
Oboe version: [1.7.5](https://github.com/google/oboe/commit/2caafd2d7dfe1612334579148447467e35e514d6)
App name used for testing: play store reports

We have been getting reports of this crash for a (long) while from google play dev console:

```
#00 pc 0x000000000004e574 /apex/com.android.runtime/lib64/bionic/libc.so (abort+180)
#01 pc 0x0000000000038b40 /system/lib64/libaaudio_internal.so (aaudio::IsochronousClockModel::convertLatestTimeToPosition(long) const+208)
#02 pc 0x00000000000344d8 /system/lib64/libaaudio_internal.so (aaudio::AudioStreamInternalCapture::processDataNow(void*, int, long, long*)+272)
#03 pc 0x00000000000337f4 /system/lib64/libaaudio_internal.so (aaudio::AudioStreamInternal::processData(void*, int, long)+332)
#04 pc 0x00000000007c7e80 ourlibrary.so (oboe::AudioStreamAAudio::read(void*, int, long)+643) (BuildId: f367ae05b14f6252284b0d34b9707bb8ae2a962a)
[...]
#45 pc 0x00000000007c791c ourlibrary.so (oboe::AudioStreamAAudio::callOnAudioReady(AAudioStreamStruct*, void*, int)+524) (BuildId: f367ae05b14f6252284b0d34b9707bb8ae2a962a)
#46 pc 0x0000000000022430 /system/lib64/libaaudio_internal.so (aaudio::AudioStream::maybeCallDataCallback(void*, int)+192)
#47 pc 0x000000000002411c /system/lib64/libaaudio_internal.so (aaudio::AudioStreamLegacy::callDataCallbackFrames(unsigned char*, int)+300)
#48 pc 0x000000000002477c /system/lib64/libaaudio_internal.so (aaudio::AudioStreamLegacy::processCallbackCommon(int, void*)+956)
#49 pc 0x00000000000792c4 /system/lib64/libaudioclient.so (android::AudioTrack::processAudioBuffer()+2372)
#50 pc 0x00000000000785c8 /system/lib64/libaudioclient.so (android::AudioTrack::AudioTrackThread::threadLoop()+312)
```

I think it's some assert in libaaudio. We tried to investigate our code, make it more robust but we weren't able to affect the rate of this particular crash.

In short, we are reading from the input stream using the syncrhonous API while in the output stream callback.

Interestingly, the distribution of devices with the most occurrences doesn't match the one for the app install base. Here are the top 10 devices (accounting for ~35% of the crashes):

```
motorola austin Mediatek MT6833V/NZA
Redmi sunny Qualcomm SM6150
T-Mobile Bethpage Mediatek MT6833
T-Mobile Augusta Mediatek MT6833
T-Mobile TorreyPines Mediatek MT6833
Redmi camellian Mediatek MT6833V/ZA
Redmi secret Mediatek MT6785
T-Mobile Sprout Mediatek MT6833V/ZA
Redmi miel Mediatek MT6781V/CD
POCO rosemary Mediatek MT6785
```

More interestingly, the Mediatek MT6833 is by far the most represented in the whole list (a couple hundred devices).

Hopefully someone here has some hunch on what we might be doing wrong, or a workaround for some known device-specific issue.