test: release experiment for v1.107.0-rc1 on ddev-test

[rfay]

…e released [skip ci]

make release-prep TAG=v1.25.4-rc1 now works: the images are published under
that exact tag and the binary built from it pulls them, while latest stays on
the last stable release.

• No issue; found while verifying release-prep buried in docs; released ddev still pulls images by hash ddev/ddev#8751.

release-prep.sh and release-marker.sh accepted only vX.Y.Z, so a
prerelease could not be stamped at all. Underneath that,
image-build-push.yml added -t latest unconditionally alongside the release
tag, which is why release-management.md told you not to run release-prep for
a prerelease: the images would have been correct, but latest would have
followed an rc.

Two questions were tangled together behind the same ^vX\.Y\.Z$ regex, and
they want different answers:

• Is this a release tag? Widened to accept -alpha/-beta/-rc in the
  three places that ask: pkg/docker/images.go, release-prep.sh, and
  release-marker.sh. Naming the kinds rather than accepting any suffix is
  what keeps git describe's v1.25.4-15-gabcdef1 and -dirty forms from
  being stamped as a release by accident.
• Should this move latest? Only image-build-push.yml was wrong here, and
  it needs no regex: release-marker.sh has already vetted the shape, so a -
  in the tag means prerelease.

Resolving to the release tag at all is about what people see — ddev version
and docker images name v1.25.4-rc1 instead of a content hash nobody
recognizes — so a prerelease wants the same treatment a stable release gets.

Deliberately unchanged: validate-image-tag.sh's rejection of release-shaped
content tags (a branch named v1.25.4-rc1 would publish
...:v1.25.4-rc1-<hash>, a different string that can't shadow a real
prerelease image); the push-tagged-*.yml validation escape hatches, so a
manual dispatch still can't hand-push a prerelease tag; and the latest gates
in containers_shared.mk and build_image.sh, which are already stable-only
and sit in image hash paths, where an edit would force every image to be
rebuilt and republished for no behavior change.

containers/release-prep.sh v1.26.0-rc1
git diff   # every Dockerfile marked v1.26.0-rc1, each <TagVar>Branch set to it
containers/release-marker.sh ddev-webserver   # v1.26.0-rc1
make && .gotmp/bin/*/ddev version   # images named :v1.26.0-rc1

containers/release-prep.sh "$(git describe --tags --always --dirty)"
containers/release-prep.sh v1.26.0-preview1

Then reset with git checkout ..

TestResolveImageTag covers the accepted prerelease kinds plus -dirty and an
unrecognized suffix falling back to the content hash. release_prep_test.sh
asserts a prerelease stamps and reads back like a release, and its
rejected-tags list now carries the git describe shapes.

latest is not covered by either, since it only happens inside
image-build-push.yml.

No change to a stable release. Worth cutting one prerelease with this in place
before relying on it, since the latest behavior can only be observed in a
real workflow run.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com<!--
PR titles have very precise rules, please read
https://docs.ddev.com/en/stable/developers/building-contributing/#pull-request-title-guidelines

If this is a nontrivial contribution, please create an issue for discussion first, or discuss it first in Discord, https://ddev.com/s/discord. This will save you time and help direct the feature.
-->

Short Summary (TL;DR)

The Issue

• Fixes #REPLACE_ME_WITH_RELATED_ISSUE_NUMBER

How This PR Solves The Issue

Manual Testing Instructions

Automated Testing Overview

Release/Deployment Notes