fix(release): tag releases v<version>, not monorepo-v<version>

[derrickmehaffy]

Good catch on the tag. The draft came out as:

tag_name  = monorepo-v5.1.0-beta
name      = monorepo: v5.1.0-beta
prerelease = true

Why

component: "" does not mean "no component". An empty string is falsy, so
release-please fell back to deriving the component from the root
package.json name — @strapi-plugin-rest-cache/monorepo → monorepo.

include-component-in-tag: false is the real switch. From util/tag-name.js:

toString() {
  if (this.component) {
    return `${this.component}${this.separator}${this.includeV ? 'v' : ''}${this.version}`;
  }
  return `${this.includeV ? 'v' : ''}${this.version}`;
}

This would have blocked the publish

Not cosmetic. npm-latest and npm-prerelease allow deployments only from
main and from tags matching v*, and a release event runs on
refs/tags/<tag>.

monorepo-v5.1.0-beta matches neither rule, so the publish job would have been
refused by the environment gate — and that failure explains itself poorly, since
it looks nothing like a tag-naming problem.

The tag becomes v5.1.0-beta: what every tag here has looked like since v4, and
what those environment rules were written for.

The existing draft has to be recreated

It is already tagged wrong, so after this merges:

1. Delete the monorepo-v5.1.0-beta draft release
2. Relabel chore: release main #209 from autorelease: tagged back to autorelease: pending
3. Re-run the release-please workflow — it recreates the draft as v5.1.0-beta

I can do all three once this is in; nothing is published yet, so there is
nothing to unwind.

Also confirmed from the draft

prerelease=true was set automatically, which answers the open question — you
will not need to tick the box by hand, and publish.yml will correctly take the
next / npm-prerelease path.

🤖 Generated with Claude Code