phase 2(android): port Oboe C++ bridge + audio FFI into wzp-native

Now that Phase 1 proved the split-cdylib pipeline (build #37 launched
cleanly with 'wzp-native dlopen OK: version=42 msg=...' in logcat),
this commit brings the real audio code into wzp-native without ever
touching the Tauri crate:

- cpp/oboe_bridge.{h,cpp}, oboe_stub.cpp, getauxval_fix.c copied
  verbatim from crates/wzp-android/cpp/ (same files that work in the
  legacy wzp-android .so on this phone)
- build.rs near-identical to crates/wzp-android/build.rs: clones
  google/oboe@1.8.1 into OUT_DIR, compiles oboe_bridge.cpp + all
  oboe source files as a single static lib with c++_shared linkage,
  emits -llog + -lOpenSLES. On non-android hosts it compiles just
  oboe_stub.cpp so `cargo check` works locally without an NDK.
- Cargo.toml gets cc = "1" in [build-dependencies]. This is SAFE
  because wzp-native is a single-cdylib crate — crate-type is only
  ["cdylib"], no staticlib, so rust-lang/rust#104707 does not apply.
- src/lib.rs extends the FFI surface with the real audio API:
    wzp_native_audio_start() -> i32
    wzp_native_audio_stop()
    wzp_native_audio_read_capture(*mut i16, usize) -> usize
    wzp_native_audio_write_playout(*const i16, usize) -> usize
    wzp_native_audio_capture_latency_ms() -> f32
    wzp_native_audio_playout_latency_ms() -> f32
    wzp_native_audio_is_running() -> i32
  Plus a static AudioBackend singleton holding the two SPSC ring
  buffers (capture + playout) that are shared with the C++ Oboe
  callbacks via AtomicI32 cursors. The wzp_native_version() and
  wzp_native_hello() smoke tests from Phase 1 are preserved.

Compiles cleanly on macOS host with the stub oboe .cpp. Next build
will exercise the full cargo-ndk path inside docker to verify the
whole Oboe compile still works standalone.

Phase 3 (next commit): wzp-desktop engine.rs on Android calls
wzp-native's audio FFI via the already-wired libloading handle, and
the real CallEngine::start() is implemented for Android using the
same codec/handshake/send/recv pipeline as desktop but with Oboe
rings instead of CPAL rings.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

crates/wzp-native/Cargo.toml

@@ -15,8 +15,15 @@ description = "WarzonePhone native audio library — standalone Android cdylib t
 name = "wzp_native"
 crate-type = ["cdylib"]
 
+[build-dependencies]
+# cc is SAFE to use here because this crate is a single-cdylib: no
+# staticlib in crate-type → no rust-lang/rust#104707 symbol leak. The
+# legacy wzp-android crate uses the same setup and works.
+cc = "1"
+
 [dependencies]
-# Phase 1 scaffold: no dependencies at all. Pure Rust FFI smoke test so we
-# can validate the standalone-cdylib + libloading runtime pipeline before
-# bringing Oboe / wzp-codec / etc. back in. Phase 2 will add the Oboe cc
-# build and the actual audio pipeline.
+# Phase 2: Oboe C++ audio bridge. Still no Rust deps — we do the whole
+# audio pipeline via extern "C" into the bundled C++ and expose our own
+# narrow extern "C" API for wzp-desktop to dlopen via libloading.
+# Phase 3 can add wzp-proto/wzp-codec if we want to share codec logic
+# instead of calling back into wzp-desktop via callbacks.