docs/release-notes: use per-PR fragments

CONTRIBUTING.md

@@ -20,6 +20,9 @@ This is a rough outline of what a contributor's workflow looks like:
 - Create a topic branch from where you want to base your work (usually main).
 - Make commits of logical units.
 - Make sure your commit messages are in the proper format (see below).
+- Add a descriptively named release-note fragment for user-visible changes. See
+  [`docs/release-notes.d/README.md`](docs/release-notes.d/README.md) for the
+  filename format, categories, and validation commands.
 - Push your changes to a topic branch in your fork of the repository.
 - Make sure the tests pass, and add any new tests as appropriate.
 - Submit a pull request to the original repository.

docs/release-notes.d/azure-provider-unit-tests.change.md

@@ -0,0 +1,2 @@
+<!-- release-note-pr: 2345 -->
+Add Azure provider unit tests covering the fallback to custom data when IMDS userdata is empty and the indefinite wait for a missing OVF config drive

docs/release-notes.d/butane-inline-gzip-validation.bugfix.md

@@ -0,0 +1,4 @@
+<!-- release-note-pr: 2343 -->
+Butane: report an error when `compression: gzip` is set on inline contents
+that are not gzip-compressed, instead of generating a config that fails at
+first boot

docs/release-notes.d/go-fix-pipeline.change.md

@@ -0,0 +1,2 @@
+<!-- release-note-pr: 2346 -->
+Restore `go fix` behavior on go.yml pipeline