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>

README.md

@@ -239,6 +239,10 @@ make desktop-install  # menu entry + icon
 make helper-install   # the privileged blocking helper
 make report           # build and send today's report right now
 make android-install  # build and install the phone client
+make lint             # ruff, the same invocation CI uses
+make ci-test          # every suite, with no venv assumed
+make android-release  # the release APK
+make ci-runner        # start the Gitea Actions runner
 make deploy           # push master and redeploy kadence.timka.su
 ```
 
@@ -254,6 +258,54 @@ python -m app.cli set-password  # set/rotate the web login password (prompts, ne
 
 ---
 
+## Continuous integration
+
+Gitea Actions, in `.gitea/workflows/`:
+
+| Workflow | When | What |
+| --- | --- | --- |
+| `test.yml` | push to master, every PR | backend (73), desktop (47), `:core` (196), and the web app's typecheck + build — four parallel jobs, none of which may need a running backend |
+| `lint.yml` | push to master, every PR | `ruff check` over `backend/` and `desktop/`, with the rule set named in `backend/pyproject.toml` |
+| `docker.yml` | push to master, `v*` tags | builds the image, starts it against SQLite and waits for `/api/health`, then pushes `git.timka.su/timka123/kadence:latest` and `:<short-sha>` |
+| `android-release.yml` | push to master, `v*` tags | `:app`'s Robolectric suite (44), then the release APK — signed from secrets, with `apksigner verify` printing the certificate it actually used |
+
+**Nothing runs until a runner is registered.** `docker-compose.ci.yml` is the whole
+of that, and its header is the setup checklist: a registration token from
+*Settings → Actions → Runners*, then `make ci-runner`. Gitea itself needs
+`[actions] ENABLED = true` and `DEFAULT_ACTIONS_URL = github` in `app.ini`, the
+second so `actions/checkout@v4` can be resolved.
+
+Two details decide whether the jobs work at all:
+
+* **The label map.** `runs-on: ubuntu-latest` is pinned to
+  `catthehacker/ubuntu:act-24.04` by the runner's own config, because the jobs need
+  two things from the image: a `node` (Gitea's javascript actions run *inside* the
+  job container) and Python 3.12, which the backend's `requires-python` insists on.
+* **The docker socket**, mounted into job containers so the image can be built. It
+  needs both the mount and `valid_volumes` naming it — see `deploy/act-runner.yaml`.
+
+Secrets, all under *Repository → Settings → Actions → Secrets*:
+
+| Secret | For |
+| --- | --- |
+| `REGISTRY_USER`, `REGISTRY_TOKEN` | pushing to the Gitea registry (a token with `package:write`) |
+| `KADENCE_KEYSTORE_BASE64` | `base64 -w0 your.keystore` |
+| `KADENCE_KEYSTORE_PASSWORD`, `KADENCE_KEY_ALIAS`, `KADENCE_KEY_PASSWORD` | the key inside it |
+
+With no keystore secret the APK job still runs and still produces an artifact —
+debug-signed, which is fine for installing on your own phone and no use for
+anything else. With one, `KADENCE_REQUIRE_SIGNING` makes a missing or misnamed
+secret **fail the build**: the Gradle config otherwise falls back to the debug key
+without a word, and a debug-signed "release" installs happily and can then never
+be upgraded by a properly signed one.
+
+The Glyph Matrix AAR is deliberately not fetched in CI — its licence forbids
+redistribution, and the build compiles the `noglyph` source set without it, so a
+CI APK has an inert rear display. That is also the correct behaviour on any phone
+that is not a Nothing.
+
+---
+
 ## Going public
 
 Kadence is still single-user: `AUTH_USERNAME`/`AUTH_PASSWORD` and