chore: prepare the 2.2.0 release (#660)

Bumps every version surface to 2.2.0, fixes a latent version-coupling bug in the
OCR runtime tests, and stops an absent GPU runner from silently stalling a
release.

Version surfaces: scripts/sync-version.sh covers the 11 workspaces, APP_VERSION,
and the docs release commands across all locales. Root package.json plus the
three surfaces the script never reaches are done by hand: the DOCKERHUB.md banner
and tag table, the docker-tags.md pinning table in 21 locales, and the example
runtimeVersion in tools/image/ocr.md in 21 locales. The release-notes archive step
is deliberately not pre-run, so the notes text stays editable until the release.

Latent bug: runtime-state rejects any runtime whose compatibility.snapotterVersion
is not exactly APP_VERSION, and five fixtures pinned the literal 2.1.0. Since
semantic-release rewrites APP_VERSION on every release, the first PR after any
bump would have gone red for a reason nobody would trace to the release. The
fixtures now derive from APP_VERSION.

GPU runner: sign-ocr-index needs verify-ocr-nvidia on self-hosted hardware, and
the gated manifest job needs ai-bundles, so a missing runner queued instead of
failing and produced no image tags. preflight-gpu-runner claims the same labels
with no dependencies, so it is scheduled first and validates the GPU before the
90-minute build. An API preflight is impossible because listing self-hosted
runners needs Administration:read, which GITHUB_TOKEN cannot hold, so RELEASE.md
carries the maintainer-side check.

apps/docs/pl/guide/docker-tags.md

@@ -141,8 +141,8 @@ Dla akceleracji NVIDIA CUDA przez Docker Compose dodaj sekcję deploy do usługi
 | Tag | Opis |
 |-----|------------|
 | `latest` | Najnowsze wydanie |
-| `2.1.0` | Dokładna wersja |
-| `2.1` | Najnowsza łatka w 2.1.x |
+| `2.2.0` | Dokładna wersja |
+| `2.2` | Najnowsza łatka w 2.2.x |
 | `2` | Najnowsza wersja podrzędna w 2.x |
 
 ## Platformy {#platforms}

apps/docs/pl/guide/getting-started.md

@@ -59,7 +59,7 @@ Użyj pliku produkcyjnego utrzymywanego i testowanego w każdym wydaniu, zamiast
 ```bash
 install -d -m 700 snapotter && cd snapotter
 curl --proto '=https' --tlsv1.2 -fsSLo docker-compose.yml \
-  https://raw.githubusercontent.com/snapotter-hq/SnapOtter/v2.1.0/docker/docker-compose.yml
+  https://raw.githubusercontent.com/snapotter-hq/SnapOtter/v2.2.0/docker/docker-compose.yml
 
 # Keep generated service credentials out of shell history and world-readable files.
 umask 077
@@ -72,7 +72,7 @@ docker compose -f docker-compose.yml pull
 docker compose -f docker-compose.yml up -d --no-build
 ```
 
-Kanoniczny [`docker/docker-compose.yml`](https://github.com/snapotter-hq/SnapOtter/blob/v2.1.0/docker/docker-compose.yml) obejmuje wszystkie cztery woluminy wykonawcze, kontrole stanu, limity zasobów, trwałą konfigurację Redis, przypięte obrazy bazy danych/pamięci podręcznej oraz bieżące zabezpieczenie kontenera. Zmień domyślne hasło administratora natychmiast po pierwszym logowaniu. Aby zapewnić powtarzalne wdrożenie, przypnij obraz aplikacji SnapOtter do zweryfikowanego znacznika wydania lub podsumowania, zamiast podążać za `latest`.
+Kanoniczny [`docker/docker-compose.yml`](https://github.com/snapotter-hq/SnapOtter/blob/v2.2.0/docker/docker-compose.yml) obejmuje wszystkie cztery woluminy wykonawcze, kontrole stanu, limity zasobów, trwałą konfigurację Redis, przypięte obrazy bazy danych/pamięci podręcznej oraz bieżące zabezpieczenie kontenera. Zmień domyślne hasło administratora natychmiast po pierwszym logowaniu. Aby zapewnić powtarzalne wdrożenie, przypnij obraz aplikacji SnapOtter do zweryfikowanego znacznika wydania lub podsumowania, zamiast podążać za `latest`.
 
 Zobacz [Konfiguracja](/pl/guide/configuration) w celu uzyskania wszystkich zmiennych środowiskowych oraz [Zabezpieczenia i wzmacnianie](/pl/guide/security), aby uzyskać informacje tajne, zasady sieciowe i wskazówki dotyczące tworzenia kopii zapasowych.
 

apps/docs/pl/guide/security.md

@@ -243,7 +243,7 @@ Każde wydanie SnapOtter zawiera następujące artefakty zabezpieczeń:
 Pobierz manifest tematu wydania i sprawdź, czy został on potwierdzony w przepływie pracy wydania:
 
 ```bash
-gh attestation verify snapotter-v2.1.0-release-subjects.json \
+gh attestation verify snapotter-v2.2.0-release-subjects.json \
   --repo snapotter-hq/SnapOtter \
   --signer-workflow snapotter-hq/SnapOtter/.github/workflows/release.yml
 ```
@@ -254,13 +254,13 @@ Możesz także zeskanować pobrany plik SBOM lub obraz bezpośrednio:
 
 ```bash
 # Scan with Grype using the CycloneDX SBOM
-grype sbom:snapotter-v2.1.0-image-linux-amd64-sbom.cdx.json
+grype sbom:snapotter-v2.2.0-image-linux-amd64-sbom.cdx.json
 
 # Scan with Trivy using the SPDX SBOM
-trivy sbom snapotter-v2.1.0-image-linux-amd64-sbom.spdx.json
+trivy sbom snapotter-v2.2.0-image-linux-amd64-sbom.spdx.json
 
 # Scan the Docker image directly
-trivy image snapotter/snapotter:2.1.0
+trivy image snapotter/snapotter:2.2.0
 ```
 
 ::: info