fix(ci): use github.run_number in firebase-tests RUN_URL

Forgejo's web URL for an Actions run is
`/{owner}/{repo}/actions/runs/{run_number}`, not the internal `run_id`. The
auto-created failure issue linked to `${{ github.run_id }}` which produced
a 404 (e.g. /actions/runs/4657175) instead of the working
/actions/runs/2403 link. Without a working log link, agents and humans
cannot diagnose the actual test failure.

Switch to `${{ github.run_number }}` so future failure issues link to a
real run page. This matches how `run_number` is already used in the
runner-wait-time API queries elsewhere in the workflow.

Refs #560

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

.forgejo/workflows/firebase-tests.yml

@@ -109,7 +109,7 @@ jobs:
         env:
           FORGEJO_TOKEN: ${{ github.token }}
           FORGEJO_URL: ${{ github.server_url }}
-          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_number }}
         run: |
           python3 - << 'PYEOF'
           import os, json, urllib.request, urllib.error

ISSUE-555.md

@@ -1,46 +0,0 @@
-## Background
-
-PR #554 fixed the Firebase Test Lab build by chaining `./gradlew --stop` after `flutter build apk` so the daemon releases its journal-cache lock before Dagger snapshots the layer. This issue asks whether that daemon is useful in the first place — and if not, suppress it instead of cleaning up after it.
-
-## Answer to the question
-
-**The daemon provides zero benefit in this CI path, and there is no "existing daemon" for it to reuse.**
-
-- Each Dagger `WithExec` runs in its own ephemeral container. When `flutter build apk` returns, the container is torn down and the daemon process is killed. The only thing that survives is on-disk state on the `gradle-cache` volume mount (`/home/ci/.gradle`), including the journal-cache lock file naming the now-dead PID.
-- The next exec (`./gradlew --no-daemon app:assembleAndroidTest`) runs in a fresh container with PID 1 = gradlew. There is no live daemon process to connect to, and `--no-daemon` would refuse to anyway — but it still has to *acquire* the journal-cache lock and times out because the stale lock file is still there.
-- So the daemon's one job (persist between invocations to amortize JVM startup) cannot happen here: invocation boundaries are container boundaries. The daemon only exists long enough to perform a single build, then is killed — i.e., it behaves like `--no-daemon` but with extra cleanup hazards.
-
-## Proposed change
-
-Prevent the daemon from spawning in CI instead of stopping it afterward. This makes `flutter build apk` behave the same way `./gradlew --no-daemon app:assembleAndroidTest` already does, removes the `bash -c "... && ./gradlew --stop"` wrapper, and eliminates the class of stale-lock failures rather than the one observed instance.
-
-### `ci/main.go`
-
-1. In `firebaseBase()` (and `androidBase()` for consistency — same cache mount, same risk surface), add an env var that disables the Gradle daemon for every invocation in those containers:
-   ```go
-   WithEnvVariable("GRADLE_OPTS", "-Dorg.gradle.daemon=false")
-   ```
-   Scoped to CI containers only, so local `./gradlew` still gets a daemon.
-
-2. In `BuildAndroidDebugApks()`, revert the first `WithExec` to its pre-#554 form:
-   ```go
-   WithExec([]string{"flutter", "build", "apk", "--debug", "--no-pub"}).
-   ```
-   Drop the `bash -c "... && ./gradlew --stop"` wrapper and the comment block explaining the lock-file workaround.
-
-3. In the second `WithExec`, drop the `--no-daemon` flag since `GRADLE_OPTS` now covers it. Update the adjacent comment (currently explaining stale-daemon-registry reuse) to point at the env-var approach instead, or remove it.
-
-### Why `GRADLE_OPTS=-Dorg.gradle.daemon=false` and not `gradle.properties`
-
-`android/gradle.properties` is checked into the repo and read on every developer machine. Setting `org.gradle.daemon=false` there would slow down local Android builds (every `flutter run` would pay full JVM startup). The env var keeps the change inside the CI module.
-
-## Verification
-
-- `dagger call test-android-firebase ...` (or whatever invocation #554 was validated against): build APK + androidTest APK succeed end-to-end with no `--stop` step and no journal-lock timeout.
-- Confirm the Gradle log from `flutter build apk` shows `Daemon will be stopped at the end of the build` / no "Starting a Gradle Daemon" line, or at minimum that no daemon process is left running before container teardown.
-- `assembleAndroidTest` continues to succeed on a warm `gradle-cache` (dependencies still cached on the volume; only the daemon state is disabled).
-
-## Out of scope
-
-- Touching `gradle.properties` (developer-facing, daemon still wanted locally).
-- Changing the `gradle-cache` mount to non-persistent — defeats the dependency-caching benefit, which is the actual reason the mount exists.