ci(docker-publish): serialise publishes so two runs cannot race :latest

[acamarata]

Three triggers feed this workflow — tag push, cli-release dispatch, manual dispatch — and nothing stopped them overlapping.

This fired for real today. Two dispatches for 1.3.6 ran simultaneously (17:02:37 and 17:04:52); one was cancelled by hand. Both would have pushed :X.Y.Z, :X.Y, :X and :latest. The last writer of :latest wins, so a slower run of an older version can land on top of a newer one and silently become what every docker pull nself/nself-admin receives.

#105 had just removed release.yml's ungated publisher for the same class of reason. This is that problem one layer up — between two runs of the gated publisher itself.

Two deliberate choices

The group is a constant, not the version. Serialising per-version would still let 1.3.6 and 1.3.7 race, and the shared floating tags are exactly what they contend for. One image, one publisher.

cancel-in-progress: false. Cancelling a publish mid-push is not a safe stop — that is what happened to release.yml on v1.3.6, killed partway through pushing with the manifest unfinished. A queued run costs minutes; a half-pushed manifest is a broken :latest.

Trade-off, stated rather than hidden

GitHub keeps only one pending run per group, so a third request cancels the second while it waits. That is the right outcome for the duplicate-dispatch case this fixes (same version twice — drop the redundant one). For three distinct versions queued at once it would drop the middle one. The Hygiene release-tag gate catches a version whose image never published, and releases here are sequential and rare.

Verified: pure addition (28 insertions, 0 deletions, no existing key changed); workflow still parses with all three triggers and the docker-publish job intact.