ci: gitea actions for the suites, the image and the APK

Four workflows, none of which existed:

* `tests.yml` — backend, desktop, `:core` and the web app's typecheck+build, in
  parallel. `:core` needs no Android SDK at all, because settings.gradle.kts
  leaves `:app` out when there is none; `:app`'s Robolectric suite therefore
  lives in the APK workflow, where the SDK is installed anyway. Nothing needs a
  running backend — the suites feed on committed fixtures, which is the whole
  reason they were written that way.
* `lint.yml` — ruff, which the repo had been configured for and never run.
* `docker.yml` — builds the image, *starts* it against SQLite and waits for
  /api/health before pushing, then publishes `:latest` and `:<short-sha>` to
  git.timka.su. A tag nobody can run is worse than no tag.
* `android-release.yml` — the release APK on every push to master, signed from
  secrets, with `apksigner verify --print-certs` reporting which key was really
  used and failing if it was the debug one.

Three things the repo needed before any of that could work:

`versionCode` was pinned at 1, so every APK looked like the same version to the
phone and would not install over its predecessor. It now comes from the run
number, with `versionName` from a property, both via one `setting()` helper that
reads a Gradle property or an environment variable.

The release build fell back to the *debug* signing key whenever the keystore was
missing — silently. That is a trap: the APK installs, looks fine, and can never
be upgraded by a properly signed build. `KADENCE_REQUIRE_SIGNING=1` makes that
case fail the build instead, and the release job sets it whenever a keystore
secret is present.

The compose files built an image with no name, so there was nothing to pull.
`image:` now names the registry tag while `up --build` still builds locally.

Also: `android/ci/install-sdk.sh` (idempotent, cacheable, and the one place that
knows `platforms;android-37.0` is spelled with the minor version), the runner as
a compose service with its config and a setup checklist, six make targets, and a
README section. No runner is registered yet — `make ci-runner` is step two of
that checklist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitea/workflows/test.yml

@@ -0,0 +1,99 @@
+# The suites, on every push and pull request.
+#
+# All four are offline by design: the backend only ever runs on one machine, so
+# nothing here may need it up. Fixtures and fakes, never a live server.
+#
+# `ubuntu-latest` is whatever the runner's label map points at — see
+# `docker-compose.ci.yml`, which pins it to catthehacker/ubuntu:act-24.04 for the
+# two things every job needs: a node (Gitea's javascript actions run inside the
+# job container) and Python 3.12, which the backend requires.
+name: tests
+
+on:
+  push:
+    branches: [master]
+  pull_request:
+
+env:
+  DEBIAN_FRONTEND: noninteractive
+
+jobs:
+  backend:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install Python tooling
+        run: |
+          apt-get update -qq
+          apt-get install -y --no-install-recommends python3-venv >/dev/null
+          python3 -m venv /tmp/venv
+          /tmp/venv/bin/pip install -q -e "./backend[dev]"
+
+      - name: pytest
+        working-directory: backend
+        run: PYTHONPATH="$PWD" /tmp/venv/bin/python -m pytest -q
+
+  desktop:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      # No PyQt6 and no display: nothing under desktop/tests imports Qt. The
+      # three modules it covers — the blocker manager, the DNS stub, the mini
+      # timer's geometry — are plain standard library, which is why they are
+      # testable at all. `pythonpath = ["."]` is already in the pytest config.
+      - name: Install pytest
+        run: |
+          apt-get update -qq
+          apt-get install -y --no-install-recommends python3-venv >/dev/null
+          python3 -m venv /tmp/venv
+          /tmp/venv/bin/pip install -q pytest
+
+      - name: pytest
+        working-directory: desktop
+        run: /tmp/venv/bin/python -m pytest -q
+
+  web:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/cache@v4
+        continue-on-error: true
+        with:
+          path: frontend/node_modules
+          key: npm-${{ hashFiles('frontend/package-lock.json') }}
+
+      - name: Install, typecheck, build
+        working-directory: frontend
+        run: |
+          npm ci --no-audit --no-fund
+          npm run typecheck
+          npm run build
+
+  android-core:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      # `:core` is plain Kotlin on the JVM and `settings.gradle.kts` only
+      # includes `:app` when an SDK is present, so this job needs a JDK and
+      # nothing else. The `:app` unit tests run in the release workflow, where
+      # the SDK has to be installed anyway.
+      - name: Install JDK 21
+        run: |
+          apt-get update -qq
+          apt-get install -y --no-install-recommends openjdk-21-jdk-headless >/dev/null
+
+      - uses: actions/cache@v4
+        continue-on-error: true
+        with:
+          path: ~/.gradle/caches
+          key: gradle-core-${{ hashFiles('android/gradle/libs.versions.toml', 'android/gradle/wrapper/gradle-wrapper.properties') }}
+
+      - name: gradlew :core:test
+        working-directory: android
+        env:
+          JAVA_HOME: /usr/lib/jvm/java-21-openjdk-amd64
+        run: ./gradlew --no-daemon :core:test