changelog: carryReleasedParent drops a stacked child's lines that sit inside a released parent's span #3589

What happened

When #3572 was retargeted to main after its stack parents #3564 and #3567 squash-merged, mergeChangelogs(ours=33f29a3, theirs=main@edf4c2e, base=621baec) returned null. The same happens with the true merge base, 4c745ee. The lane needed an owner-approved hand CHANGELOG (train 44/45, GSTA-147).

Cause

carryReleasedParent (lib/changelog-check.ts) is designed for this case. The child's [Unreleased] held PR 2's entry, PR 1's entry and PR 3's own two lines, and PR 3's lines sat inside PR 1's paragraph: a bullet between PR 1's last ### Changed bullet and its ### Tests heading, and a test bullet inside PR 1's Tests list. The hunk rule "Lines added between two of the parent's own lines … belong to its entry" counts both lines as additions to the 1.91.306.0 entry. Nothing of the child's own is left, kept.some(content) is false, and the function returns null. changelogDamage then refuses: ours's Unreleased holds released 1.91.307.0 text.

Expected

Lines that are the child's own diff against the fork point (here, git diff 621baec 33f29a3 -- CHANGELOG.md adds exactly those two lines) should stay in the child's section, not become "Addition to the entry" bullets. Then the merge gives main's file plus an [Unreleased] section with only the child's lines. That's the result the lane wrote by hand: changelogDamage returns null on it, and mergeChangelogs(hand, main, base) round-trips it byte for byte.

Repro

PR #3572 at 33f29a3 against main edf4c2e, base 621baec. A test could add a fixture to the existing carryReleasedParent cases: two released parents, with the child's lines interleaved inside the older parent's span.