Drop the one-shot dist-tag script; the commands live in the doc

The registry maintenance is four npm dist-tag commands the operator
runs once; a committed script outlives its single use. The versioning
doc names the command shape instead.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Author: wmadden-electric

.drive/projects/prisma-cli-v8/deferred.md

@@ -23,9 +23,8 @@ Nothing here is tracked outside this file.
 - **The `@prisma/cli` deprecation call is open.** Rollout-plan step 5
   listed a deprecation notice pointing installers at `prisma`; the
   package is now the scoped twin the workflow actively publishes, so
-  deprecating it may no longer make sense. Operator decision; needs
-  npm auth either way (`scripts/cutover-dist-tags.sh` carries a
-  commented-out line for it).
+  deprecating it may no longer make sense. Operator decision; needs npm auth either way
+  (`npm deprecate @prisma/cli@"<8.0.0" "..."`).
 
 ## After S7's first real publish
 

docs/oss/versioning.md

@@ -40,7 +40,7 @@ This is enforced, not remembered: the conformance checks refuse to publish a rel
 The npm registry exposes the CLI packages under these dist-tags:
 
 - **`latest`** — what a bare `npm install` gets: the newest release, RC or stable. A merged release PR publishes here automatically (operator cutover ruling 2026-08-25; before it, `latest` stayed on the pre-8 CLI and the RC line lived on `next`).
-- **`next`** — kept alive but no longer moved by the publish path (operator ruling 2026-08-25). Removing it would break every `prisma@next` instruction immediately, and an automated sync to `latest` would need a standing token — re-pointing a tag on an already-published version cannot authenticate over OIDC, and npm has no token permission narrower than package write, which is publish-capable. So the operator points it at the current release by hand (`scripts/cutover-dist-tags.sh`), accepts that it lags between such moves — a lagging `next` still resolves a complete, working release — and retires it with an announcement once `8.0.0` stable ships. New text should say plain `prisma`.
+- **`next`** — kept alive but no longer moved by the publish path (operator ruling 2026-08-25). Removing it would break every `prisma@next` instruction immediately, and an automated sync to `latest` would need a standing token — re-pointing a tag on an already-published version cannot authenticate over OIDC, and npm has no token permission narrower than package write, which is publish-capable. So the operator points it at the current release by hand (`npm dist-tag add prisma@<version> next`, same for `@prisma/cli` and the engine), accepts that it lags between such moves — a lagging `next` still resolves a complete, working release — and retires it with an announcement once `8.0.0` stable ships. New text should say plain `prisma`.
 - **`beta`** — reserved for hand-cut previews ahead of significant changes, published by dispatching the workflow with that dist-tag. Routine releases do not use this tag.
 
 - **`dev`** — every routine push to `main` publishes `<base>-dev.<run>` here automatically (operator ruling 2026-08-13, superseding the earlier "no dev channel" ruling). The suffix derives from the workflow run number and is stamped ephemerally in CI, never committed, so release versions remain exactly what a commit says. The channel exists so a product's new version reaches a working CLI without a human: an auto-merging pull request moves the version, runs the full quality and conformance checks, and its merge ships the dev build. Today a daily scheduled run is what notices a product release; the immediate path needs a notification step in each product repository, which neither has yet. See [release automation](./release-automation.md). Only a real release — a merged `rc.N` bump publishing under `latest` — is a human act.