Stop claiming the app crates cannot cross-compile

The note above the core-crate check said the UI and app crates would join
"once the Android shell exists". They already had. Building `darkroom-android`
for aarch64 takes 4m23s and produces `libdarkroom.so`, linked for Android 28 —
which is what the step below now checks, and what a device installs.

Rewritten to say what the core check is actually for: a fast, link-free gate
that fails early and names a smaller suspect, ahead of the full build.

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

.gitea/workflows/build-and-test.yml

@@ -94,8 +94,15 @@ jobs:
             target-android
           key: android-${{ hashFiles('**/Cargo.lock') }}
 
-      # Only the core crates cross-compile today; the UI and app crates join
-      # once the Android shell exists (milestone v0.1, FR-PLAT-AND-*).
+      # A fast gate on the crates most likely to break the cross-compile, run
+      # before the expensive part. It is `cargo check`, so it type-checks
+      # without linking and returns in a fraction of the time the step below
+      # takes.
+      #
+      # Not a statement that only these crates cross-compile — `darkroom-android`
+      # and the whole UI stack beneath it build for aarch64 too, which is what
+      # the API-level step below does. This one exists to fail fast and name a
+      # smaller suspect when it does.
       - name: Cross-compile core
         env:
           CARGO_TARGET_DIR: target-android