Publish current 1.1 Docker image and safely replace legacy v0.5 tags

[goniszewski]

Problem

The public Docker Hub tags goniszewski/grimoire:latest and :preview still point to the legacy v0.5 application. The current Grimoire 1.1.0 rewrite has a supported Dockerfile and Compose path, but it is not a drop-in runtime or data-layout upgrade.

The legacy Compose setup uses /app/data; the current image uses /data. v0.5 migration is explicit and experimental, so moving latest without a documented migration path could make existing users start the new application without their old library.

References:

• Docker Hub: https://hub.docker.com/r/goniszewski/grimoire/tags
• Current Docker deployment guide: https://github.com/goniszewski/grimoire/blob/main/docs/docker-deployment.md
• v0.5 migration guide: https://github.com/goniszewski/grimoire/blob/main/docs/migration.md

Goal

Publish the current 1.x Docker image for fresh installs while preserving a recoverable path for existing v0.5 Docker users.

Requirements

• Build from the released v1.1.0 / origin/main baseline, not an unreleased develop checkout.
• Publish multi-architecture images for linux/amd64 and linux/arm64.
• Publish an exact release tag such as 1.1.0, with a documented policy for rolling 1.1 and latest tags.
• Preserve the current legacy image digest under an explicit tag such as legacy-v0.5 before moving latest.
• Add reproducible Docker Hub publication automation with authenticated registry access and image metadata.
• Update the Compose or quick-start path so users can pull the published image; the current Compose file builds locally from the repository.
• Document the v0.5 Docker migration: back up/export the old /app/data volume, start the current image with its /data volume, and use the supported migration inspection/dry-run/apply workflow.
• Keep the documented loopback-only host port and warn against public 3210 exposure.
• Run clean-pull smoke tests on both architectures covering health, UI access, bookmark persistence across restart, and backup/restore.
• Verify that the old legacy tag remains pullable and that moving latest does not claim automatic in-place migration.

Acceptance criteria

• A fresh user can pull the documented current image and reach the 1.x UI on port 3210.
• The exact version tag resolves to the tested multi-architecture image.
• Existing v0.5 users have a tested, non-destructive migration procedure and a clearly preserved legacy image reference.
• Docker documentation, Compose configuration, and release tags agree on the image name, version, port, volume, and network boundary.
• The latest cutover is performed only after the migration and persistence checks pass.