Trigger CI on next, not only main (closes #122)

`check.yml` ran only on push to `main` and on pull requests against `main`. Every unit is a PR based on `next`, and `next` is pushed on each squash-merge, so no unit PR and no push to `next` ever ran CI; a broken `next` would first surface on the milestone PR. `next` is added to both branch lists; nothing else in the workflow changes. The README Entrypoints section now says where CI runs.

Disclosure: the CI run on the PR itself fired (the proof the trigger works) but was red because the runner had no disk space left before any check step ran; the local gate was green.

Model: opus-4-8 (implementation and review)
model: claude-fable-5

.gitea/workflows/check.yml

@@ -1,9 +1,9 @@
 name: check
 on:
   push:
-    branches: [main]
+    branches: [main, next]
   pull_request:
-    branches: [main]
+    branches: [main, next]
 jobs:
   check:
     runs-on: ubuntu-latest

README.md

@@ -716,6 +716,8 @@ them. We provide:
   then the product image). Either failing fails the script. It runs the
   checks in the same containers CI does, from a clean copy of the tree,
   so it also catches anything that depends on host state.
+  `.gitea/workflows/check.yml` runs it on every push to `main` and
+  `next` and on every pull request against either.
 
   It passes a fresh `--build-arg CHECK_EPOCH` to each build, unique per
   invocation, which both files declare immediately above their check

TODO.md

@@ -25,6 +25,12 @@ release" is exactly the contradiction
 
 # Completed Steps
 
+- 2026-09-21: Made `.gitea/workflows/check.yml` run on pushes to `main`
+  and `next` and on pull requests against either, so unit PRs (whose
+  base is `next`) and `next` itself get a CI run instead of relying on a
+  local `make check`
+  ([issue #122](https://git.eeqj.de/sneak/vaultik/issues/122)).
+
 - 2026-08-10: Moved every lint run into its own container, as a build
   step ([issue #113](https://git.eeqj.de/sneak/vaultik/issues/113)).
   New root `Dockerfile.lint`, built by `script/lint`, runs