fix: correct tag prefix and drop the unusable release fallback tag

[pannoury]

What broke

The Python and PHP publish jobs failed on the merge of #11 with:

Error: Couldn't find the latest tag. Make sure you have at least one tag created or provide a fallbackTag!

fallbackTag was set. Reading ietf-tools/semver-action@v1.11.0, the fallback is gated on semver.valid(fallbackTag) — and python/v1.0.0 is not valid semver, so it was silently discarded and the job fell through to the error. The fallback expects the bare version, with the prefix supplied separately.

That is moot anyway: the action's own docs say "The fallback tag must exist already", because immediately afterwards it calls compareCommitsWithBasehead against <prefix><tag>. A fallback pointing at a tag that was never created cannot work. It has been removed rather than corrected.

Also fixed

Double v in every tag name. The action emits next as `${prefix}v${version}` — it adds the v itself. With prefix: javascript/v the first release would have been tagged javascript/vv1.0.1. The prefix is now javascript/ and the tag comes out as javascript/v1.0.1, which is what the version-strip steps downstream already assume.

Tag lookup window too small. maxTagsToFetch defaulted to 10, and the action fetches the newest tags across the whole repo before filtering by prefix. With three languages releasing independently, a quiet language's last tag drops out of a 10-tag window and its next release resolves against the wrong base. Raised to 100.

Seed tags created

The repository had no tags at all, and nothing is published on npm, PyPI or Packagist. Since the fallback cannot bootstrap an empty repo, the initial tags were pushed by hand at the initial commit (9511b85):

javascript/v1.0.0
python/v1.0.0
php/v1.0.0

The next merge that touches a language directory compares against its tag and, with patchAll: true, publishes 1.0.1. Version 1.0.0 itself is never published — it only exists as the starting point.

Merge order

Merge this first. It only touches .github/workflows/, which the release paths-filter ignores, so merging it publishes nothing. Then merge #12, which fixes the JavaScript build that failed on the #11 merge — that one touches all three directories and will trigger the first real release.