ci: publish the container image to the Gitea registry

Adopts the release scheme from legacy-email-proxy so both repositories behave
the same way: the version is derived from conventional commits since the last
v* tag, the image is pushed under the full version, the truncated major.minor
and major forms, and latest, and non-release builds are published as
sha-<short>. Multi-arch (amd64 for the NAS, arm64 so the same image runs on a
Pi). Authentication uses the PACKAGES_SECRET repository secret.

The release step also writes the computed version into pyproject.toml and
commits it as chore(release) before tagging, so the packaging metadata cannot
drift behind the release. It skips the commit when the file already carries
that version, which would otherwise fail the job after the image had been
pushed.

compose.yaml and the README now reference the published image instead of
instructing the NAS to build one locally.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -60,14 +60,16 @@ both provide them.
 
 ## Running it on TrueNAS Scale
 
-`compose.yaml` is a Custom App definition. Build the image on the NAS, adjust
-the two host paths and the `user:` to match your pool, then add it as a custom
-app:
+`compose.yaml` is a Custom App definition. Adjust the two host paths and the
+`user:` to match your pool, then add it as a custom app. The image is published
+to this Gitea's registry on every release:
 
-```sh
-git clone https://code.emmathe.dev/lyrathorpe/music-mirror
-cd music-mirror && docker build -t music-mirror:latest .
 ```
+code.emmathe.dev/lyrathorpe/music-mirror:latest
+```
+
+Tags are `latest`, the full version, and the truncated `major.minor` and
+`major` forms; builds that are not releases are published as `sha-<short>`.
 
 Point the mirror at its own dataset rather than a directory inside the music
 dataset — it is derived data, so it wants its own snapshot policy, its own