chore(release): reconcile 81 changelog.d fragments into CHANGELOG [3.8.47]

[brick30llc-ctrl]

What

Folds all 81 pending changelog.d/ fragments into the ## [3.8.47] section of CHANGELOG.md and deletes the fragment files — the standard reconciliation step, run via the repo's own script:

node scripts/release/aggregate-changelog.mjs

Breakdown: 17 features + 58 fixes + 6 maintenance = 81 fragments → 81 new bullets (149 total in the [3.8.47] section).

Verification

• npm run check:changelog-integrity → OK — no base bullets lost vs origin/release/v3.8.47.
• Diff scope is exactly CHANGELOG.md (+82) and the 81 fragment deletions — nothing else.

Scope / notes

• The changelog i18n mirror (release:sync-changelog-i18n, version-parameterized) and the final date-stamp (## [3.8.47] — TBD → dated) are intentionally left to the /generate-release finalization flow — this PR is just the fragment fold.
• Non-destructive proposal: if this isn't merged, the fragments simply remain on release/v3.8.47 and /generate-release aggregates them normally at finalization. Merge this to lock in reconciliation early, or let the release flow supersede it — either is safe.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[diegosouzapw]

Thanks for the contribution and for running the aggregation script correctly — check:changelog-integrity does pass, and the diff is clean (no bullets lost).

That said, this step is intentionally owned by the release captain / /generate-release workflow, not run mid-cycle by individual PRs. From changelog.d/README.md:

The release captain (or /generate-release) folds all fragments into CHANGELOG.md and deletes them

and CONTRIBUTING.md: "fragments are aggregated at release time and never conflict between PRs." The whole point of the fragments-first design is that PRs never touch CHANGELOG.md or interfere with the reconciliation, which happens once, at release time, together with the Contributors hall and the dated header.

There's also a concrete staleness issue: release/v3.8.47 currently has 99 pending fragments, not 81 — 18 more (including #6862, #6838, and #6908) merged after this branch was cut, so this PR's fold is already incomplete on arrival. Merging it wouldn't save the release captain any work; Phase 0a would still need to re-run the aggregation for the remainder.

Closing as belonging to another flow — no action needed on your end, this will happen automatically at release time. Appreciate you understanding the reconciliation-timing convention.

We genuinely appreciate the initiative and attention to the release tooling — please keep contributing! Your #6944 backslash-escape fix is exactly the kind of PR that helps: small, well-tested, and scoped. Bug fixes, features, and per-PR changelog fragments (changelog.d/{features,fixes,maintenance}/<PR>-<slug>.md) are always welcome.