fix(release): fit an oversized CHANGELOG section into the Release body

[DemchaAV]

Why

release.yml publishes a tag's CHANGELOG section as the body of its GitHub Release, and GitHub refuses a body over 125 000 characters. The 2.4.0 section is over 156 000, so on the v2.4.0 tag the Create or update GitHub Release step failed with HTTP 422: body is too long (maximum is 125000 characters), after verify and the knowledge bundle had both passed. The v2.4.0 Release was then created by hand with a condensed body. Re-running the workflow could not help: the edit path posts the same body and hits the same limit.

What changed

• scripts/release-notes.mjs — takes the extracted section. One that fits is left byte for byte. A longer one becomes its heading, every ### subsection, and each entry cut to its bold lead sentence, followed by a link to the full section at the tag. The CHANGELOG already writes that lead to be read on its own. An entry whose lead is only a name, such as `SvgGlyph.fromFile(Path)`., keeps the rest of its first sentence. A lead with no closing ** is published as its first line rather than dropped.
• release.yml — the notes step runs the script right after the awk extraction, so both gh release create and gh release edit get a body that fits. Node is already set up earlier in the job for the knowledge bundle.
• scripts/release-notes.test.mjs — run by a new step in release-script-check.yml, whose path filter now also covers the script, its test and release.yml. Cases:
  • the real 2.4.0 section, extracted the way release.yml does, fits: 7 264 characters, all 99 entries, all 8 subsections in order, every lead bold, and the link to the tag;
  • the 2.3.0 section passes through unchanged;
  • a name-only lead keeps its sentence, and an unterminated lead survives;
  • release.yml still calls the script between the extraction and gh release create.
• docs/contributing/release-process.md — step 8 says what happens to a section over the limit.

Limit: if even the condensed body exceeded the limit (on the order of a thousand entries), the Release would still be refused. No CHANGELOG section is near that.

Lane: build / release tooling. No runtime code, no public API.

Verification

• node scripts/release-notes.test.mjs — 11 cases pass.
• Sabotage, each caught:
  • the size check forced to "fits" → 4 cases fail: fits a Release, every lead bold, links to the tag, unterminated lead;
  • the call deleted from release.yml → the workflow-order case fails.
• node scripts/release-notes.mjs <extracted v2.4.0 section> v2.4.0 DemchaAV/GraphCompose → notice: 156 097 characters condensed to 7 264, 99 entry leads. Called without arguments → usage message and exit 2.
• ./mvnw -B -ntp test -f core/pom.xml -Dtest='com.demcha.documentation.**' — 143 tests, 0 failures, BUILD SUCCESS (the knowledge-gate guards parse release.yml).