step E.minus-1: cpp_smoke renamed to .c and compiled as plain C

c++_shared crashed, c++_static crashed, no stdlib crashed. The remaining
variable isolated to cc::Build::new().cpp(true) itself is the C++
compile-mode invocation of clang++. Rename cpp_smoke.cpp → cpp_smoke.c
and drop .cpp(true), leaving a plain-C cc::Build that compiles the
exact same bytes (minus the 'extern "C"' linkage spec which is C++-
only syntax).

This is structurally identical to Step A (hello.c), which worked. If
THIS build launches, the diff between 'works' and 'crashes' is purely
the .cpp(true) mode — something clang++ does differently at compile
or link time when producing object files for a Tauri Android cdylib.

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

desktop/src-tauri/cpp/cpp_smoke.c

@@ -0,0 +1,9 @@
+// cpp_smoke.c — Step E.minus-1: same content as the crashing .cpp file
+// but as plain C. No extern "C" linkage spec (that's C++-only syntax;
+// in C every function has C linkage by default). If this crashes we
+// know cc::Build is being wrongly accused — the trigger must be more
+// general than C++ mode.
+
+int wzp_cpp_hello(void) {
+    return 42;
+}

desktop/src-tauri/cpp/cpp_smoke.cpp

@@ -1,14 +0,0 @@
-// cpp_smoke.cpp — Step E.1: the absolute minimum C++ file.
-// No #include, no STL, no atomics, no thread, no mutex. Just one function.
-// Still compiled as .cpp(true) with cpp_link_stdlib("c++_shared"), so the
-// only delta vs the non-crashing baseline is:
-//   1. cc::Build using cpp(true) (vs plain C in hello.c)
-//   2. cargo:rustc-link-lib=c++_shared emitted by cc-rs (adds NEEDED
-//      entry for libc++_shared.so in the final .so)
-//
-// If this crashes, we've conclusively proven the trigger is one of those
-// two things — not any C++ code behavior.
-
-extern "C" int wzp_cpp_hello(void) {
-    return 42;
-}