publish_release 409s on the publish-non-default-then-flip-later flow (tag exists)

The Build M flip surfaced a gap: publishing with --no-latest (immutable tag now, default decision later) then re-running the default publish to move latest.json fails —

HfHubHTTPError: 409 Conflict ... Tag reference exists already

_create_release_tag has no exists-tolerance, and --no-create-tag is (correctly) refused when the manifest pins artifacts to the release id. So the intended two-step flow — publish immutable, flip on the maintainer's word — cannot complete through the CLI.

Workaround used for the Build M flip (2026-07-17): upload latest_pointer_payload(release_id) directly as latest.json via HfApi.upload_file — the exact payload/paths the publisher's final step writes, verified afterwards through latest_release().

Fix options: (a) treat an existing tag at the same revision as success (verify the tag's revision matches the just-uploaded content before proceeding — exists-at-different-revision stays fatal); (b) a dedicated --latest-only mode that validates the tag + release files exist and writes only the pointer. (a) keeps one command; (b) makes the two-step flow first-class.

Start by tracing the CLI publish flow through _create_release_tag and the final latest.json write, then review latest_pointer_payload, latest_release, and the HfApi.upload_file workaround described in the issue. Done means the immutable-then-default publish flow completes without a 409, while an existing tag at a different revision remains fatal; the issue does not name a test file.