refactor(workflows)!: rename the floating tag to workflows-v0

[metalwarrior665]

Renames the floating workflow tag v0 → workflows-v0, and writes down the constraint that actually governs it.

Why

The package releases from this repo as v0.9.0, v0.8.6 and so on (15 such tags). A bare v0 sat in that same namespace and read like a package version. A future v1 beside a package v1.0.0 would have been worse.

Free to do right now because no consumer has repointed to v0 yet. After repos migrate, renaming is a flag day.

What this does not do

It does not make releases safer, which is worth stating because it looks like it should.

git-cliff — which computes the next package version — parses every tag as semver and aborts on one that isn't. Tested: workflows-v0 aborts exactly as v0 did (unexpected character 'w'), and it also matches an unanchored v[0-9]+ because it contains v0. Both names survive only because apify/actions/git-cliff-release ships tag_pattern = "v[0-9]+\.", whose trailing dot excludes them.

Nothing is broken today. The master run after v0 was created computed 0.9.1 and published correctly, and --bumped-version gives v0.10.0 for the next stable.

So rather than engineering around it, CONTRIBUTING now records:

• the tag is skipped only because of that pattern, and a release failing with the semver error means the pattern changed, not that something here is wrong
• the workflows- prefix protects the reader, not the tooling
• the action's "Nothing to release" guard no longer fires — it uses raw git describe --tags --abbrev=0, which ignores tag_pattern and resolves to the floating tag, so an empty stable release now fails at npm publish instead of erroring cleanly

Owning a repo-local cliff.toml would genuinely remove the dependency, but it means maintaining 115 lines and 21 commit-parser rules that define the changelog format — disproportionate for a pattern whose dot looks deliberate, since bare major tags are the standard Actions convention.

After merge

The master-push job creates workflows-v0 on its own. The old v0 tag must then be deleted by hand — nothing removes it, and leaving it keeps both the confusion and the git-cliff exposure alive:

git push origin :refs/tags/v0

Verification

• check-major-tag-refs.mjs passes, and still fails when one ref is left at @v0
• actionlint 1.7.11 + shellcheck 0.10.0, check-package-version-bump.mjs, lint, type-check, build, 222 tests, prettier — all green
• External pins (claude-code-action@v1, setup-node@v5, …) untouched

🤖 Generated with Claude Code

https://claude.ai/code/session_01SkUZADZ6gzWW4GE6CFMreM

---

Generated by Claude Code

[ruocco-l]

Two nits on verbosity, but other than that it's fine