Switch changelog handling to fragments

[huitseeker]

This changes PR changelog work from direct edits to CHANGELOG.md into fragment files under .changes/unreleased/. A PR now passes if it adds a valid fragment or has the no changelog label. This keeps the main changelog curated and cuts down merge conflicts.

When a PR is missing both a fragment and the label, the workflow posts a comment that shows the exact file path to add and one suggested fragment. It suggests content for both local and foreign PRs, but it never pushes changes to the PR branch.

Release prep is now a separate manual workflow. It reads unreleased fragments, merges them into CHANGELOG.md, and moves the consumed files into .changes/archive/<version>/.

stateDiagram-v2
    [*] --> PR
    PR --> Passes: fragment present
    PR --> Passes: `no changelog` label
    PR --> NeedsFragment: neither present

    NeedsFragment --> Draft
    Draft --> Suggest: model writes fragment text
    Suggest --> Passes: contributor adds fragment
    Suggest --> Passes: maintainer adds label

    Passes --> ReleasePrep
    ReleasePrep --> Changelog: batch fragments into `CHANGELOG.md`
    Changelog --> Archive: move fragments to `.changes/archive/<version>/`
    Archive --> [*]

Loading

This depends on GitHub Models being enabled and actions/ai-inference being allowed. actionlint, shell syntax checks, Python compilation, fragment validation, and release batching were all checked locally. GitHub Actions execution itself was not tested here.

[bitwalker]

Nice! Big +1 on this effort. I absolutely hate how simple CHANGELOG entries conflict every single time. This will make the chances of merge conflicts go way down.

I like the general approach - I may incorporate this in the compiler repo as well once this is all tidied up and been used for a bit. We do use release-plz there, but we can just disable the CHANGELOG generation.

[Nashtare]

That's definitely neater than the current CHANGELOG flow. However this remains manual, with users having to specifically write a fragment for their work which should still ideally (in the future?) be fully abstracted away and only enforcing PR name semantics.

[bobbinth]

I haven't looked into the actual changes yet, but how does this jive with the changelog proposal from @WiktorStarczewski and @Keinberger? I believe there we wanted to use a specific format to make it easy for AI agents to write migration guides.

[huitseeker]

@Nashtare @bobbinth a few follow-ups here.

The fragment check now uses the same parser as release prep. It still requires kind, pr, and a non-empty summary, but it now accepts normal YAML details like quoted values, comment lines, null for crate, and extra front matter keys. That keeps the required fields strict without boxing us in if we want richer fragment metadata later.

Release prep is deterministic: it batches fragments by PR number, then filename. It also flushes old .changes/archive/* entries before writing the current release batch, so the archive does not keep growing over time.