ci: split plugin prerelease validation

docs/reference/RELEASING.md

@@ -216,8 +216,9 @@ Validation` or from the `main`/release workflow ref so workflow logic and
   before the release publish path
 - If the release work touched CI planning, extension timing manifests, or
   extension test matrices, regenerate and review the planner-owned
-  `checks-node-extensions` workflow matrix outputs from `.github/workflows/ci.yml`
-  before approval so release notes do not describe a stale CI layout
+  `plugin-prerelease-extension-shard` matrix outputs from
+  `.github/workflows/plugin-prerelease.yml` before approval so release notes do
+  not describe a stale CI layout
 - Stable macOS release readiness also includes the updater surfaces:
   - the GitHub release must end up with the packaged `.zip`, `.dmg`, and `.dSYM.zip`
   - `appcast.xml` on `main` must point at the new stable zip after publish
@@ -306,10 +307,11 @@ ids, so after a child workflow is rerun successfully, rerun only the failed
 `Verify full validation` parent job.
 
 For bounded recovery, pass `rerun_group` to the umbrella. `all` is the real
-release-candidate run, `ci` runs only the normal CI child, `release-checks` runs
-every release box, and the narrower release groups are `install-smoke`,
-`cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live`, and
-`npm-telegram` when the standalone package Telegram lane is supplied.
+release-candidate run, `ci` runs only the normal CI child, `plugin-prerelease`
+runs only the release-only plugin child, `release-checks` runs every release
+box, and the narrower release groups are `install-smoke`, `cross-os`,
+`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live`, and `npm-telegram` when the
+standalone package Telegram lane is supplied.
 
 ### Vitest