fix: bake the NDK into the image so debugSymbolLevel works

ndk { debugSymbolLevel = "SYMBOL_TABLE" } needs the NDK's llvm-objcopy
to extract native symbol tables into the .aab's BUNDLE-METADATA. The
image shipped no NDK, so AGP silently skipped the step and Play warned
"no debug symbols" on every bundle with native code (confirmed by
inspecting Dade's 0.0.2 .aab: onnxruntime .so present, debugsymbols
metadata dir absent).

Install ndk;27.0.12077973 (AGP 8.13's default, so app repos need no
android.ndkVersion), export ANDROID_NDK_ROOT/HOME, and add llvm-objcopy
to the image sanity check so an arch/version mismatch fails the image
build instead of silently dropping symbols downstream.

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

README.md

@@ -22,8 +22,11 @@ so building on amd64 costs nothing on the output side.
 ## What's in the image
 
 - Eclipse Temurin JDK 21 (native amd64)
-- Android cmdline-tools, platform, and build-tools — **baked in**, so prod
-  builds don't depend on Google's download endpoint at job time
+- Android cmdline-tools, platform, build-tools, and **NDK** — **baked in**, so
+  prod builds don't depend on Google's download endpoint at job time. The NDK is
+  what makes `ndk { debugSymbolLevel }` work: AGP shells out to its
+  `llvm-objcopy` to embed native symbol tables in the `.aab`, so Play can
+  symbolicate native crashes. Without it AGP skips that step silently.
 - `git`, `curl`, `unzip`
 - Node.js 24 — so Gitea Actions JS actions (`actions/checkout`,
   `upload-artifact`, …) run when this image is used as a job `container`
@@ -35,6 +38,7 @@ Pinned versions live as `ARG`s at the top of the `Dockerfile`:
 | `CMDLINE_TOOLS_VERSION` | `13114758`  | https://developer.android.com/studio#command-line-tools-only |
 | `BUILD_TOOLS_VERSION`   | `36.0.0`    | SDK Manager / release notes |
 | `PLATFORM_VERSION`      | `android-36`| your app's `compileSdk` |
+| `NDK_VERSION`           | `27.0.12077973` | AGP's default NDK: https://developer.android.com/build/releases/gradle-plugin |
 
 The build-tools binaries (`aapt2`, `d8`) are x86_64 ELF — this is why the
 image is amd64 (see "Why amd64" above).