spec: un-splice the FOUR paragraph in both default-change reasons, and tighten one phrase

Contract review F4: the FOUR paragraph was inserted BEFORE the last clause of each
reason string rather than after it, so both reasons rendered with two sentences cut
in half — "…what he now reads is what the ⚠️ FOUR published JSON Schemas change
projection direction…" and "…not a new one. parser has always applied." The gate's
own text says the reason is printed by every build that accepts the change and must
be written for the consumer who is about to be surprised; that consumer was being
handed broken sentences. The paragraph now sits at the end of each string, and both
reasons were read back as rendered from the module and from the accepting build's
own output.

Also tightens the phrase the review found loose. It said the two nested defs gain a
required member "with no default to declare". They do carry defaults — enabled is
true, rules is [] — and both were already published at the base: measured, not
inherited, at authorable-defaults/system.json lines 206 and 248 of the base blob,
whose base..head diff is exactly +slis and +sampling, two insertions and no
deletions. The wording is now the changeset's own: only the first two carry a
default MOVE, so only those two are declarable here, because this ratchet records
default VALUES per key and is blind to required growth by construction.

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

Author: claude

packages/spec/scripts/lib/default-changes.ts

@@ -381,17 +381,21 @@ export const DEFAULT_CHANGES_BY_MAJOR: Readonly<Record<number, readonly Declared
         + 'present — and those cells carried `?` at the base. Nothing '
         + 'deployed changes behaviour; the consumer affected is one outside this repo who reads '
         + 'the published JSON Schema\'s `default` himself, and what he now reads is what the '
-        + '⚠️ FOUR published JSON Schemas change projection direction in this diff, not the two this '
-        + 'table has rows for, and the other two are disclosed nowhere else: `system/MetricsConfig` and '
-        + '`system/TracingConfig` lose `x-io: input` AND gain a `default` (these two rows), while the '
-        + 'nested `system/ServiceLevelIndicator` and `system/TraceSamplingConfig` lose `x-io: input` '
-        + 'and gain a `required` MEMBER with no default to declare — `enabled` and `rules` respectively — '
-        + 'so this ratchet never sees them. Measured at head: all four carry no `x-io` and `required` '
-        + 'lists the defaulted keys; ten other `system` defs are still input-mode, and the same-category '
-        + 'control `system/CacheConfig` is untouched. A `required` that lists defaulted keys is this '
-        + 'repo\'s existing output-mode convention, not a new one. '
         + 'parser has always applied. To keep the old value there is nothing to write — the key, '
-        + 'its type and its default are unchanged.',
+        + 'its type and its default are unchanged.'
+        + ' ⚠️ FOUR published JSON Schemas change projection direction in this diff, not the two '
+        + 'this table has rows for, and the other two are disclosed nowhere else: '
+        + '`system/MetricsConfig` and `system/TracingConfig` lose `x-io: input` AND gain a `default` '
+        + '(these two rows), while the nested `system/ServiceLevelIndicator` and '
+        + '`system/TraceSamplingConfig` lose `x-io: input` and gain a `required` MEMBER — `enabled` '
+        + 'and `rules` respectively — whose defaults (`true` and `[]`) were ALREADY PUBLISHED at the '
+        + 'base and did not move. Only the first two carry a `default` MOVE, so only those two are '
+        + 'declarable here: this ratchet records default VALUES per key, so it is blind to `required` '
+        + 'growth by construction, and the nested pair has no row it could live in. Measured at head: '
+        + 'all four carry no `x-io` and `required` lists the defaulted keys; ten other `system` defs '
+        + 'are still input-mode, and the same-category control `system/CacheConfig` is untouched. A '
+        + '`required` that lists defaulted keys is this repo\'s existing output-mode convention, not '
+        + 'a new one.',
     },
     {
       key: 'system/TracingConfig:sampling',
@@ -412,17 +416,21 @@ export const DEFAULT_CHANGES_BY_MAJOR: Readonly<Record<number, readonly Declared
         + 'key of every `system/TracingConfig` nested type cell (`parentBased`, `propagation`, '
         + '`spanLimits`, `performance`, `instrumentation`), the output-mode signature. '
         + 'Nothing deployed changes behaviour; the consumer affected is one outside this '
-        + '⚠️ FOUR published JSON Schemas change projection direction in this diff, not the two this '
-        + 'table has rows for, and the other two are disclosed nowhere else: `system/MetricsConfig` and '
-        + '`system/TracingConfig` lose `x-io: input` AND gain a `default` (these two rows), while the '
-        + 'nested `system/ServiceLevelIndicator` and `system/TraceSamplingConfig` lose `x-io: input` '
-        + 'and gain a `required` MEMBER with no default to declare — `enabled` and `rules` respectively — '
-        + 'so this ratchet never sees them. Measured at head: all four carry no `x-io` and `required` '
-        + 'lists the defaulted keys; ten other `system` defs are still input-mode, and the same-category '
-        + 'control `system/CacheConfig` is untouched. A `required` that lists defaulted keys is this '
-        + 'repo\'s existing output-mode convention, not a new one. '
         + 'repo who reads the published JSON Schema\'s `default` himself. To keep the old value '
-        + 'there is nothing to write — the key, its type and its default are unchanged.',
+        + 'there is nothing to write — the key, its type and its default are unchanged.'
+        + ' ⚠️ FOUR published JSON Schemas change projection direction in this diff, not the two '
+        + 'this table has rows for, and the other two are disclosed nowhere else: '
+        + '`system/MetricsConfig` and `system/TracingConfig` lose `x-io: input` AND gain a `default` '
+        + '(these two rows), while the nested `system/ServiceLevelIndicator` and '
+        + '`system/TraceSamplingConfig` lose `x-io: input` and gain a `required` MEMBER — `enabled` '
+        + 'and `rules` respectively — whose defaults (`true` and `[]`) were ALREADY PUBLISHED at the '
+        + 'base and did not move. Only the first two carry a `default` MOVE, so only those two are '
+        + 'declarable here: this ratchet records default VALUES per key, so it is blind to `required` '
+        + 'growth by construction, and the nested pair has no row it could live in. Measured at head: '
+        + 'all four carry no `x-io` and `required` lists the defaulted keys; ten other `system` defs '
+        + 'are still input-mode, and the same-category control `system/CacheConfig` is untouched. A '
+        + '`required` that lists defaulted keys is this repo\'s existing output-mode convention, not '
+        + 'a new one.',
     },
   ],
 };