Release-tagged container images are overwritten on each push to main

The Build And Push Dock Image action, which runs on each push to main, tags the images pushed with the latest release version.
For example, the commit fa55c3af0d4f38d371934d4a8b9d4b02bf068d17 (which was pushed after v0.1.1 was published) built and published a new container image tagged as 0.1.1, overriding the image originally published for the v0.1.1 release.

This can cause problems for people relying simply on the tag of the container image.
For people pinning the image digest this only causes some minor annoyances, e.g. because tools like renovate will try to upgrade the pinned digest even though the image tag hasn't changed.

A possible fix could be using a pseudo-version in the version file on main, and only setting the "real" version for the commit a release is published on.

Alternatively, the GitHub action responsible for publishing the image could only set the version tag when the action is run for a release.
Possible options for this include using an on-release event trigger, or manually running the workflow and adding a user input to control tagging of the final image

Review .github/workflows/docker-publish.yml and prepline_general/api/version.py, starting with the workflow's version-tagging step and how main pushes differ from releases. Choose and implement an approach that prevents pushes to main from overwriting release-tagged images while preserving the intended version tag for published releases.