ci(mobile): fix Gradle daemon Metaspace OOM + Android lint ExtraTrans…

…lation

Two independent root causes found via rc6 autopsy + the overnight EAS
cloud build's log, both fixed:

1. Gradle daemon Metaspace OOM (killed rc6, 64min silent stall until the
   step timeout reaped it). Gradle's own default org.gradle.jvmargs
   (-Xmx512m -XX:MaxMetaspaceSize=384m) is too low for this project; the
   daemon threw repeated OutOfMemoryError: Metaspace ~12 minutes into
   :app:bundleRelease and wedged instead of dying cleanly. EAS's own cloud
   workers avoid this entirely via GRADLE_OPTS="-Dorg.gradle.jvmargs=...
   -Dorg.gradle.daemon=false" (confirmed against their own build logs) --
   matched here. Per Gradle's docs, org.gradle.jvmargs (not GRADLE_OPTS
   alone) is what actually controls the build JVM's memory, so it's set
   via ~/.gradle/gradle.properties (global, outside the gitignore-filtered
   shallow copy eas build --local stages, so it can't be dropped like the
   GoogleService files were). GRADLE_OPTS=-Dorg.gradle.daemon=false is set
   on the build step's own env, since that flag IS forwarded via
   GRADLE_OPTS per Gradle's docs -- a persistent daemon buys nothing on an
   ephemeral single-build CI runner and removes this whole failure class.

2. Android lintVitalRelease ExtraTranslation error (killed the 2026-07-05
   overnight EAS cloud build in a clean, fast 24min run -- unrelated to
   the OOM above, just also fatal). Root cause: app.config.ts's `locales`
   map only generates locale-TAGGED Android resource dirs
   (values-b+en/, values-b+pt+BR/), never the base values/strings.xml
   Android treats as default. Lint flags any string present in a
   locale-tagged file but absent from the default as an orphaned
   translation. Added plugins/withDefaultLocaleStrings.js, a config
   plugin that seeds values/strings.xml with the primary locale's native
   strings so lint has a default-locale baseline. Verified locally:
   `gradlew :app:lintVitalRelease` now passes (previously failed on this
   exact check).

Claude-Session: https://claude.ai/code/session_01DiAd7HvAMJn9KZtGEex4qr

ci(mobile): bump Android build timeout, guarantee Gradle cache save

A cold-cache first run on a hosted 4-core runner (no ~/.gradle to
restore, eas build --local doing its own prebuild on top of gradlew
bundleRelease) can plausibly exceed 60 minutes; not pathological, just
slow. Bumped the job timeout to 90 minutes.

Also: job-level timeout-minutes, if hit, kills the whole runner process
tree immediately -- it does NOT let subsequent if: always() steps run
(unlike an ordinary step failure, which does leave the rest of the job
to execute). That means the previous combined actions/cache step's
post-job save hook was not guaranteed to fire on a timeout kill, so a
slow first run would never leave a warm cache behind for the next
attempt. Split into restore/save actions with an explicit step-level
timeout (80 min) on the eas build step itself, shorter than the job's 90,
so that step can fail cleanly with headroom left in the job for the
always() Gradle cache save to actually run afterward.

Claude-Session: https://claude.ai/code/session_01DiAd7HvAMJn9KZtGEex4qr