fix: correct the published image tag in release notes and drop duplicate latest

[a-effort]

Problem

docker pull ghcr.io/contextforge-org/contextforge-web-ui:v0.1.0 fails with not found.

The image published fine — the advertised tag is just wrong. docker/metadata-action's type=semver,pattern={{version}} strips the leading v from the git tag, so git tag v0.1.0 publishes as image tag 0.1.0. What's actually on GHCR:

0.1.0, 0.1, latest

But the release body built its pull command from github.ref_name — the raw git tag — so it advertised :v0.1.0, a tag the workflow never pushes. DOCKER.md had the same :vX.Y.Z mistake in both the pull command and the compose-override example. This would have been wrong for every future release, not just v0.1.0.

Changes

80c1024 — document the tag that's actually published

• Release body now uses steps.meta.outputs.version (the primary derived tag) instead of github.ref_name.
• DOCKER.md: pull command and compose example corrected to :X.Y.Z, plus an explicit note that the image tag drops the v the git tag carries — this is the part that surprised people.

6dfc36e — stop deriving latest twice

The metadata step derived latest twice on every stable release ("tag-names":["0.1.0","0.1","latest","latest"]). metadata-action's default flavor is latest=auto, which already emits latest for stable semver refs, so the explicit type=raw,value=latest,enable=... line was redundant.

Worth noting the redundant line was not a broken prerelease guard — latest=auto excludes prereleases by design ("Pre-release (rc, beta, alpha) will only extend {{version}}"), so prereleases were protected from clobbering latest by two mechanisms instead of one. This was cosmetic. latest=auto is now pinned explicitly rather than left implicit, and the prerelease guard is handled by auto's semver parsing instead of a string check for - in the ref name.

Verification

Confirmed against the live registry (anonymous token, so the package is public):

$ curl .../v2/contextforge-org/contextforge-web-ui/tags/list
{"tags":["0.1.0","0.1","latest","sha256-fef06089..."]}

$ HEAD manifests/v0.1.0  -> 404
$ HEAD manifests/0.1.0   -> 200

npm run format:check passes.

Not verifiable without cutting a release: both changes only take effect on a tag-push run, so neither is exercised by CI here. The workflow's workflow_dispatch can be dispatched from the tag to prove it, but that would re-push 0.1.0/latest over the existing digest.

Follow-up (not in this PR)

• The existing v0.1.0 release page still shows :v0.1.0 — its notes were rendered at run time. Being corrected by hand separately.
• The v0.1.0 release is flagged prerelease on GitHub, though prerelease: ${{ contains(github.ref_name, '-') }} should evaluate false for v0.1.0. Possibly toggled manually. Flagging in case it's unintended.