docs(changeset): the manifest serializer forwards seven keys per input, not six

Three pending changeset bodies said `manifestFromConfigs` forwards "exactly
six keys per input" and listed six. The serializer has forwarded a seventh,
`of`, since the member-kind change (objectui#8067), whose own pending
changeset already says "seven keys per input instead of six"; all four
publish in the same release. Each list now names `of` and the count agrees
with it. Frontmatter is byte-identical; each paragraph's conclusion (the
retired key cannot reach sdui.manifest.json) is unchanged, since none of the
retired keys is `of`.

Claude-Session: https://claude.ai/code/session_01BA3nKVUwKQJf8DBxrSVtNC
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/5905-componentinput-inputtype-tombstone.md

@@ -29,7 +29,7 @@ over the same regions, so the instrument was not blind. The other 192 in-repo `i
 hits are a DIFFERENT face: `FormField.inputType` (`zod/form.zod.ts`), the text-input
 renderer's prop, and `SchemaBuilder.inputType`, none of which sit on a `ComponentInput`.
 The publication path is unchanged and was re-confirmed: `packages/sdui-parser/src/index.ts`
-forwards exactly six keys per input — `name`, `type`, `required`, `enum`, `binding`,
+forwards exactly seven keys per input — `name`, `type`, `of`, `required`, `enum`, `binding`,
 `description` — so an authored `inputType` could not reach the published
 `sdui.manifest.json` even in principle.
 

.changeset/5905-componentinput-retire-constraint-keys.md

@@ -7,8 +7,8 @@ Retire `ComponentInput`'s four inert constraint keys — `min`, `max`, `step` an
 
 All four were declared on `ComponentInput` and read by nothing, on either path. No consumer
 reads them off a `ComponentInput` value, and the manifest serializer
-(`packages/sdui-parser/src/index.ts`) forwards exactly six keys per input — `name`, `type`,
-`required`, `enum`, `binding`, `description` — so a value authored here could not reach the
+(`packages/sdui-parser/src/index.ts`) forwards exactly seven keys per input — `name`, `type`,
+`of`, `required`, `enum`, `binding`, `description` — so a value authored here could not reach the
 published `sdui.manifest.json` even in principle. Re-measured on this branch's merge-base
 rather than inherited from the card: a structural census over every `inputs:` array in the
 repository (219 regions, all tracked files) scores `min` **0**, `max` **0**, `step` **0**

.changeset/7493-componentinput-retire-label-defaultvalue-advanced.md

@@ -32,8 +32,8 @@ They are the three keys the manifest serializer does not forward, and nothing re
 publication or consumption path.
 
 No manifest ever published them, so no consumer could ever have read them. `sdui-parser`'s
-serializer (`packages/sdui-parser/src/index.ts`) forwards exactly six keys per input — `name`,
-`type`, `required`, `enum`, `binding`, `description` — so a value authored under any of the three
+serializer (`packages/sdui-parser/src/index.ts`) forwards exactly seven keys per input — `name`,
+`type`, `of`, `required`, `enum`, `binding`, `description` — so a value authored under any of the three
 never reached `sdui.manifest.json`, the generated JSX `.d.ts`, or a diagnostic; its boundary type
 has no slot for them; the registry's data-source seam reads `name` only; and neither the designer
 nor the app-shell inspectors consult registry `inputs` at all. A structural census over every