android(audio): Usage::VoiceCommunication + MODE_IN_COMMUNICATION, default handset

With da106bd (Usage::Media + MODE_NORMAL) audio works but is always on
the loudspeaker — we want handset as the default with a user-driven
toggle for speaker (and later bluetooth). The right Oboe usage for a
VoIP app is VoiceCommunication, which honours
AudioManager.setSpeakerphoneOn / setBluetoothScoOn for routing.

Bisection across previous builds showed that setAudioApi(AAudio) +
Usage::VoiceCommunication made the playout callback stop draining the
ring after cb#0 (build 8c36fb5 logs). Letting Oboe pick the AudioApi
implicitly keeps the callback alive — 96be740's Media-usage callbacks
fired at steady 50Hz without any explicit setAudioApi. So: keep the
Usage change, DROP the explicit AAudio force.

- oboe_bridge.cpp: Usage::VoiceCommunication, no setAudioApi, no
  ContentType override.
- MainActivity.kt: setMode(MODE_IN_COMMUNICATION) +
  setSpeakerphoneOn(false) = handset default, plus max both
  STREAM_VOICE_CALL and STREAM_MUSIC volumes for belt-and-braces.

Next build will add a JNI-based Tauri command to flip speakerphoneOn
at runtime so the user can toggle handset↔speaker during a call.

crates/wzp-native/cpp/oboe_bridge.cpp

@@ -297,6 +297,20 @@ int wzp_oboe_start(const WzpOboeConfig* config, const WzpOboeRings* rings) {
     // config that at least drove callbacks correctly, plus the
     // Kotlin-side MODE_IN_COMMUNICATION + setSpeakerphoneOn(true)
     // handled in MainActivity.kt to route audio to the loud speaker.
+    // Usage::VoiceCommunication is the correct Oboe usage for a VoIP app
+    // — it respects Android's in-call audio routing and lets
+    // AudioManager.setSpeakerphoneOn/setBluetoothScoOn actually switch
+    // between earpiece, loudspeaker, and Bluetooth headset. Combined with
+    // MODE_IN_COMMUNICATION set from MainActivity.kt and
+    // speakerphoneOn=false by default, this produces handset/earpiece as
+    // the default output.
+    //
+    // IMPORTANT: do NOT add setAudioApi(AAudio) here. Build 8c36fb5 proved
+    // forcing AAudio with Usage::VoiceCommunication makes the playout
+    // callback stop draining the ring after cb#0, even though the stream
+    // opens successfully. Letting Oboe pick the API (which will be AAudio
+    // on API ≥ 27 but via a different codepath) kept callbacks firing in
+    // every other build.
     oboe::AudioStreamBuilder playoutBuilder;
     playoutBuilder.setDirection(oboe::Direction::Output)
         ->setPerformanceMode(oboe::PerformanceMode::LowLatency)
@@ -305,7 +319,7 @@ int wzp_oboe_start(const WzpOboeConfig* config, const WzpOboeRings* rings) {
         ->setChannelCount(config->channel_count)
         ->setSampleRate(config->sample_rate)
         ->setFramesPerDataCallback(config->frames_per_burst)
-        ->setUsage(oboe::Usage::Media)
+        ->setUsage(oboe::Usage::VoiceCommunication)
         ->setDataCallback(&g_playout_cb);
 
     result = playoutBuilder.openStream(g_playout_stream);