#14: Gitea CI, registry composes, Node 22 image and changelog

- Gitea Actions: Trivy, Vitest in a Dockerfile test stage, arm64 image build, image
  scan and smoke test; releases reuse the image by content hash.
- docker-compose.<edition>.registry.yaml run the stack from the published image.
- Dockerfile: Node 22, a test stage, and no npm in the runtime image.
- README, CLAUDE.md and CHANGELOG describe the CI, the image and the release flow.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

README.md

@@ -65,7 +65,7 @@ docker compose -f docker-compose.bedrock.yaml logs -f    # follow panel + server
 
 ## Requirements
 
-- **Node.js ≥ 18** (dev) or Docker (deploy).
+- **Node.js ≥ 18** (dev; the image uses Node 22) or Docker (deploy).
 - A Docker host — the panel mounts `/var/run/docker.sock` to control the game container.
 
 ---
@@ -100,7 +100,12 @@ Open <http://localhost:3000> and log in with your password.
 
 ## Running with Docker
 
-The panel image is built locally from the included `Dockerfile` — it is **not** published to any registry, so a plain `docker compose pull`/`up` without a build step fails with *"pull access denied"*. Always build it:
+The panel image is built from the included `Dockerfile`. Two ways to run each stack:
+
+- **Build it yourself** (`docker-compose.<edition>.yaml`, `--build`): works anywhere, no registry needed.
+- **Pull the published image** (`docker-compose.<edition>.registry.yaml`): `git.lucasrguerra.dev.br/lucasrguerra/craftdock` (linux/arm64), built, scanned and smoke-tested by CI. Tags: `latest`, `X.Y.Z`, `X.Y` and `sha-<commit>`; pin one with `IMAGE_TAG`. This is what the reference Coolify deployment runs.
+
+To build it:
 
 Two reference stacks are provided:
 
@@ -268,3 +273,14 @@ src/
 ```
 
 CraftDock also keeps two metadata files at the data root (bundled into world backups): `craftdock_players.json` (persistent XUID→name player directory) and `craftdock_bedrock_ids.json` (Bedrock identity bridge). See [CLAUDE.md](CLAUDE.md) for the full architecture and contribution conventions (numbered feature branches, `#N:` commit prefix).
+
+---
+
+## Continuous integration and releases
+
+CI runs on the Gitea runners (`.gitea/workflows`):
+
+- **`ci.yml`** (branches and every Monday): Trivy on the repository (vulnerabilities, secrets, misconfiguration; the accepted `DS-0002` is documented in [`.trivyignore`](.trivyignore)), the Vitest suite inside the Dockerfile `test` stage, the arm64 image build, Trivy on the image and a smoke test (`scripts/smoke-imagem.sh`: UI served, API refuses unauthenticated requests, item icons generated, LevelDB addon loads, image healthcheck turns healthy).
+- **`release.yml`** (`main` and `vX.Y.Z` tags): if the registry already holds the image for the same content (`inputs-<hash>`), nothing is rebuilt — only the new tags are applied. On a tag it creates the Gitea release with the [CHANGELOG](CHANGELOG.md) notes.
+- To release: update the CHANGELOG and `package.json`, commit, then `git tag vX.Y.Z && git push gitea vX.Y.Z`.
+