Compile our own Java into the APK, so the classes Android constructs can exist

The APK's only dex was Slint's. `assemble-apk.sh` found `classes.dex` under
the android-activity backend's build directory and copied it in, and there was
no `javac` step and no `d8` of anything of ours — package.sh's header said so
outright, on the reasoning that the app has no Java because android-activity
calls `android_main` directly.

That reasoning holds for everything the app *calls* and fails for everything
Android *constructs*. A `ContentProvider` is instantiated by the system from
its manifest entry; nothing in the process ever reaches its constructor, so
there is no JNI route to writing one in Rust. The launch `Intent` is the same
shape of problem from the other end: it arrives through `Activity.getIntent()`,
and the activity android-activity hands out is a stock `NativeActivity` rather
than a subclass with room for code. FR-PLAT-AND-6 needs both, and FR-PLAT-AND-4
needs a foreground `Service`, which is a third.

So: everything under `apps/darkroom-android/android/java/` goes through javac
against `android.jar`, and d8 merges the classes with Slint's finished dex into
one `classes.dex`. Merging rather than emitting a second dex keeps the staging
and zip steps as they are — multidex is native at API 28, but two files to keep
in step buys nothing at this size.

The step is skipped when the tree holds no Java, which is the state this commit
leaves it in. Nothing about the APK changes until a `.java` file appears.

`-source 8 -target 8 -bootclasspath android.jar` is not caution about language
features. It is the last combination in which javac allows the boot class path
to be replaced: from `-target 9` the flag is rejected, the platform classes
come from the JDK instead of from android.jar, and the build stays green while
the device raises `NoClassDefFoundError` for a class Android never shipped.

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

docker/android/package.sh

@@ -6,11 +6,11 @@
 #
 # Gradle would add a second build system, a second dependency tree, and a
 # second place for the toolchain versions to drift out of step with the
-# Dockerfile. The four tools it would have driven — aapt2, d8, zipalign,
-# apksigner — are in build-tools already and are enough on their own, because
-# the app has no Java of its own: android-activity's glue calls android_main
-# directly, and the only classes in the APK are the ones Slint's build script
-# compiles for its own helper.
+# Dockerfile. The tools it would have driven — javac, aapt2, d8, zipalign,
+# apksigner — are in the image already and are enough on their own, because
+# the app is Rust: android-activity's glue calls android_main directly, and
+# the only Java in the APK is Slint's helper plus the handful of classes
+# Android insists on constructing itself (see assemble-apk.sh's Java step).
 set -euo pipefail
 
 HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"