fix(build): report the project version the release actually cut (#166)

project(VERSION) in the top-level CMakeLists.txt still said 0.19.0 after 0.20.0
was tagged. It is the single source of BMOE_VERSION -- the comment above it says
so, and that is the point of declaring it in one place -- so every 0.20.0 build
self-reports as 0.19.0, both in `bmoe-cli --version` and in the engine= line of
every metrics CSV it writes. Any CSV committed since 2026-08-17 names the wrong
engine, which is the kind of error that quietly poisons a benchmark read months
later. Nothing else was affected. Reported by gjjkbssg (#163).

Bumped to 0.21.0, the version being developed, with the app's versionCode and
versionName moved in step.

Batched with it, since both are small and both ship in the same release:

- Finer expert-cache rungs below 2000 MiB in the app (#146). The ladder went
  500 -> 1000 -> 2000, and that x2 is where the choice is sharp: on an 8 GB phone
  1000 MiB runs and 2000 MiB gets the app killed by the OS, so the step handed
  the user a cliff instead of a setting. 1250, 1500 and 1750 fill it; above 2000
  the existing 1000 MiB step is already a small fraction of the budget and is
  unchanged. Reported by eiffel31 (#146).

examples/android/app/build.gradle

@@ -51,8 +51,8 @@ android {
         applicationId 'io.bigmoeonedge.example'
         minSdk 29
         targetSdk 34
-        versionCode 35
-        versionName '0.20.0'
+        versionCode 36
+        versionName '0.21.0'
         buildConfigField 'String', 'GIT_SHA', "\"${gitSha}\""
         ndk {
             // The engine ships as prebuilt arm64 binaries staged by build-android.ps1.

examples/android/app/src/main/java/io/bigmoeonedge/example/AppSettings.kt

@@ -283,9 +283,15 @@ data class AppSettings(
         // per token and returns an 8-13% hit rate from a 2000-3000 MiB budget, so its cache may
         // already be below the floor's intent while sitting well above its number. These rungs are
         // here to measure where the cache stops earning the memory pressure it creates.
+        //
+        // The rungs are dense below 2000 and coarse above it, because that is where the choice is
+        // sharp: on an 8 GB phone 1000 MiB runs and 2000 MiB gets the app killed by the OS, so a
+        // x2 step there hands the user a cliff instead of a setting. Above 2000 a 1000 MiB step is
+        // a small fraction of the budget and needs no refining.
         // See docs/android-memory.md.
         const val CACHE_AUTO = -1
-        val CACHE_CHOICES = intArrayOf(CACHE_AUTO, 0, 500, 1000, 2000, 3000, 4000, 5000, 6000)
+        val CACHE_CHOICES =
+            intArrayOf(CACHE_AUTO, 0, 500, 1000, 1250, 1500, 1750, 2000, 3000, 4000, 5000, 6000)
 
         /** True for a fixed budget the engine would reject without --force-cache. */
         fun cacheNeedsForce(mb: Int) = mb in 1 until CACHE_MIN_MB