docs(core): cite the shipped 17.4.0 enumeration by version, not as pending

A release landed between writing the changeset and merging main: the two
enforcement entries that enumerate eight keys and declare the `version`
exclusion shipped in @objectstack/core@17.4.0 rather than sitting unreleased.
They describe what that release did and stay as written; the supersession is
now stated by version.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MkQhmuuJAVDjmeWNixwDDH

Author: os-bill

.changeset/plugin-version-semver-grammar.md

@@ -32,7 +32,7 @@ SemVer 2.0.0 defines prerelease and build metadata as **parts of** a semantic ve
 
 **`null` is refused on every one of the nine**, and a `type: 'ui'` plugin missing `staticPath` or `slug` is still refused with `PLUGIN_UI_REQUIRED_KEY_MISSING` inside the same envelope.
 
-⚠️ **This supersedes the eight-key enumeration** in the same release's `kernel.use()` and `LiteKernel.use()` enforcement entries, which say `version` is excluded. That was true of the change each of those describes; **nine is the current set**, and `version` is no longer excluded from anything.
+⚠️ **This supersedes the eight-key enumeration published in `@objectstack/core@17.4.0`.** Both of that release's entries — the `kernel.use()` and the `LiteKernel.use()` enforcement notes — say the enforced set is eight keys and that `version` is excluded, and both point at reconciling the two `version` spellings as separate spec work. This is that work. Those entries stay as written, because they describe what 17.4.0 did; **nine is the current set**, and `version` is no longer excluded from anything.
 
 **What actually changes behaviour, stated narrowly.** On **`ObjectKernel`** nothing moves: `PluginLoader.validatePluginStructure` already judged `version` with this exact grammar and still runs first, so a malformed `version` is still refused as `Invalid semantic version`, never as `PLUGIN_CONTRACT_VIOLATION`. On **`LiteKernel`** a plugin object with a malformed `version` — `version: 'v1.0.0'`, say — was **registered** before and is **refused** now, with `PLUGIN_CONTRACT_VIOLATION` at `'version'`. `LiteKernel` has never run the loader's structural checks, so `version` was the one declared key it did not judge at all: such a plugin was green in vitest and refused by `ObjectKernel` at production boot. That is exactly the split the `LiteKernel` convergence closed for the other eight keys, closed now for the ninth.
 

packages/core/src/plugin-contract.ts

@@ -66,13 +66,12 @@ import type { Plugin } from './types.js';
  * consumers as `CHANGELOG.md` and is what an upgrading author greps after
  * the refusal, so a shorter enumeration there does not merely omit keys —
  * it tells an author refused `at 'author'` that their key is not enforced.
- * ⚠️ The two changesets still pending in `.changeset/` when #16365 landed
- * (`enforce-plugin-schema-at-kernel-use.md`, `litekernel-enforces-plugin-contract.md`)
- * enumerate EIGHT and say `version` is excluded. That was true of the release
- * they describe and is deliberately left standing — a changeset is a record of
- * its own PR, not a live document — so #16365's own changeset carries the
- * ninth key and says in as many words that it supersedes them. This comment is
- * the authority on the CURRENT set.
+ * ⚠️ `CHANGELOG.md` is NOT a live document and is deliberately not corrected:
+ * `@objectstack/core@17.4.0` shipped with both enforcement entries enumerating
+ * EIGHT and saying `version` is excluded, which is what that release did. The
+ * #16365 changeset carries the ninth key and supersedes them BY VERSION rather
+ * than by rewriting them. ⇒ This comment is the authority on the CURRENT set;
+ * a released entry is the authority on the release it names.
  *
  * What this does NOT refuse, which is what bounds the narrowing: UNKNOWN
  * keys. `PluginSchema` is a plain `z.object` with no `.strict()` — the