changelog.d: fragment validation is red at HEAD (recurring; current count in the thread)

[vicondoa]

test-changelog is red at HEAD: 19 pre-existing fragments fail structural validation

Summary

make test-changelog (Makefile:344-347 - "the changelog policy gate (also the CI
test-changelog job)") is red on an unmodified checkout of
feat/v3-resource-runtime-rewrite. scripts/changelog-check.sh exits 1.

Because the gate validates every fragment present, not only changed ones, it
is permanently red: it can no longer distinguish a newly added fragment's
mistake from the standing 19, and any change that adds a fragment inherits the
failure. A gate that is always red provides no information at exactly the moment
it is supposed to prove something - and this one is on the shipping path.

Reproduction

$ bash scripts/changelog-check.sh; echo $?
PASS: CHANGELOG.md policy checks passed.
FAIL: changelog.d/ fragment validation failed:
  - changelog.d/2026-08-19-d2bd-runtime.md:1: content before the first '### <Section>' heading
  - changelog.d/2026-08-20-device-provider-ownership.md:1: content before the first '### <Section>' heading
  - changelog.d/2026-08-21-v3-guest-u3.md:1: content before the first '### <Section>' heading
  - changelog.d/2026-08-26-zone-only-u3.md:1: content before the first '### <Section>' heading
  - changelog.d/2026-08-26-zone-only-u4.md:1: content before the first '### <Section>' heading
  - changelog.d/2026-09-10-u12-credential-driver.md:26: unknown section 'Notes'; expected one of Added, Changed, Deprecated, Removed, Fixed, Security
  - changelog.d/adr046-u10-credential-providers.md:20: unknown section 'Follow-up'; expected one of Added, Changed, Deprecated, Removed, Fixed, Security
  - changelog.d/adr046-u11-broker-profiles.md:1: content before the first '### <Section>' heading
  - changelog.d/adr046-u11-transport-carriage.md:1: content before the first '### <Section>' heading
  - changelog.d/credential-async-user-sources.md:1: content before the first '### <Section>' heading
  - changelog.d/credential-guest-local-adapters.md:1: content before the first '### <Section>' heading
  - changelog.d/desktop-provider-ownership.md:1: content before the first '### <Section>' heading
  - changelog.d/feat-v3-resource-runtime-rewrite-u2-spec-store.md:1: content before the first '### <Section>' heading
  - changelog.d/guest-vmm-and-closure-convergence.md:1: content before the first '### <Section>' heading
  - changelog.d/nix-surface-ownership.md:1: content before the first '### <Section>' heading
  - changelog.d/process-runtime-owners.md:1: content before the first '### <Section>' heading
  - changelog.d/provider-owned-zone-projections.md:1: content before the first '### <Section>' heading
  - changelog.d/realm-compatibility-retirement.md:1: content before the first '### <Section>' heading
  - changelog.d/refactor-network-storage-activation-owners.md:1: content before the first '### <Section>' heading
  - changelog.d/v3-guest-u9-component-session.md:1: content before the first '### <Section>' heading
  See changelog.d/README.md for the fragment format.
1

Two distinct shapes, two different decisions

1. 17 fragments predate the heading requirement - they open with prose
   before the first ### <Section> heading. Format-only defect; the fix is
   placement, not content.
2. 2 fragments use unsanctioned sections - Notes
   (2026-09-10-u12-credential-driver.md:26) and Follow-up
   (adr046-u10-credential-providers.md:20). This is a policy question, not a
   typo: either the content folds into an allowed section, or the allowed set
   gains a sanctioned section (with changelog.d/README.md updated). Decide it
   once and apply it consistently - do not special-case by filename.

Proposed work

• Fix the 19 as format-only edits: move the leading prose under the correct
  ### Added|Changed|Deprecated|Removed|Fixed|Security heading. No content,
  intent, or attribution changes.
• Decide the Notes/Follow-up question once, then apply it.
• Keep the policy strict - do not relax validation to tolerate free-form prose.
  The strictness is what surfaced this.
• Land as its own unit before the rewrite's ship gate, since test-changelog is
  part of the shipping path.

Acceptance criteria

• bash scripts/changelog-check.sh exits 0 on a clean checkout and
  make test-changelog passes.
• The 19 fragments' textual content is preserved; only placement/section labels
  change.
• A newly added fragment validates with no parking/exclusion mechanism.

Non-goals

• Not relaxing the fragment format.
• Not folding fragments into CHANGELOG.md - make changelog-fold is a
  merge-time operation with its own timing.

[vicondoa]

Fixed on v3 in ef17dbf: all 21 fragments that failed validation now carry a valid section heading (Added/Changed/Fixed chosen from their own entries), the six prose fragments are single bullets with indented continuation lines, and the stray front matter in guest-vmm-and-closure-convergence.md is gone. cargo run -q -p xtask -- changelog-fold --check is clean over the whole directory, and the fold itself then landed in cade261 (379 fragments merged into CHANGELOG.md's Unreleased block); make check is 453/453 on the result.

[vicondoa]

Reopening rationale (2026-09-21): the same changelog gate is red at HEAD again - this is a recurrence of this issue's defect class, not a new one, so it is filed here rather than as a new issue.

Verified at HEAD (v3 @ 310eeaa): scripts/changelog-check.sh exits 1 and cargo run -q -p xtask -- changelog-fold --check reports the same 5 failures; the CI policy-tooling job runs //packages/xtask:policy_changelog_gate (packages/xtask/BUILD.bazel:382-398, data includes //:scripts/changelog-check.sh) via make test-policy, so the gate is red at HEAD and any PR on these branches carries a red required check.

Failing fragments (all committed):

• changelog.d/fix-u31-ownership-matrix-preflight.md:1 - heading-format (# ... title instead of ### <Section>)
• changelog.d/fix-u32-blocking-census.md:1 - same
• changelog.d/refactor-async-purity-daemon-control-plane.md:1 - content before the first section heading
• changelog.d/phase-provider-crate-isolation-closeout.md:54 - unsanctioned section 'For operators'
• changelog.d/residual-scaffolding-removal.md:38 - unsanctioned section 'Retained (recorded reasons)'

The first three landed in the last ~15h of closeout work; the last two are ~2 days old. Two distinct shapes, the same two classes #502 already distinguished: (a) heading-format defects (3 fragments - pure placement), (b) unsanctioned sections (2 fragments - the same policy question #502 raised for 'Notes'/'Follow-up'). The section question should be decided once and applied consistently, not per-file: either 'For operators' / 'Retained (recorded reasons)' become sanctioned sections (with changelog.d/README.md updated), or their content folds into an allowed section.

Acceptance criteria (as originally): bash scripts/changelog-check.sh and cargo run -q -p xtask -- changelog-fold --check both exit 0 on a clean checkout; the 5 fragments' textual content is preserved (placement/labels only); the unsanctioned-section policy decision is recorded in changelog.d/README.md; no parking/exclusion mechanism.