Write down two things releasing the fleet taught today

CHANGELOG.md

@@ -2,6 +2,11 @@
 
 ## Unreleased
 
+- Say in MAINTAINING.md that `just release-check` reporting no `Unreleased` entries straight after a cut means nothing is pending, not that the changelog was lost.
+- Say in PACKAGING.md that git files a propagation's changelog entry under a freshly dated heading silently, so the fresh-`Unreleased` rule only helps if it is remembered.
+
+## Unreleased
+
 - Fix the numbering of the release-note ordering list in MAINTAINING.md, broken while renumbering the release process in the previous change.
 - Show commits that touch nothing in `src/` in `just release-check` as a second group, instead of hiding them. Tooling, CI and documentation changes belong in the release notes too, and the old output read as a complete list while being a filtered one.
 - Fail `just build` when `uv.lock` does not name the version in `pyproject.toml`, and add `just relock` to fix it. `uv sync --frozen` does not check the project's own version, so a stale lock passed every packaging check.

MAINTAINING.md

@@ -97,6 +97,11 @@ it half-updated. Dependabot reopens it on the next run.
    gate or a contributor policy belongs in the notes under tooling. django-marina 26.3 shipped
    with nine such changes unrecorded, and django-bootstrap4 and django-bootstrap5 each found
    four or five more of their own, because the recipe only showed the first group.
+   Straight after a cut, in the window between merging the release PR and pushing the tag, this
+   prints `(none)` for the `Unreleased` entries next to every commit since the previous tag.
+   That is correct and it means nothing is pending: stamping the section removed the heading the
+   recipe looks for, and the tag it compares against is still the old one. It does not mean the
+   changelog was lost.
 2. On a release branch, update `CHANGELOG.md`, bump `version` in `pyproject.toml`, and run
    `just relock` so `uv.lock` names the new version; open a PR and merge it. `uv sync --frozen`
    does not check the project's own version, so a stale lock otherwise survives every packaging

PACKAGING.md

@@ -162,3 +162,9 @@ If a release PR is open in a sibling, land it or close it before propagating the
 propagation lands first and `## Unreleased` has meanwhile become a dated heading, add a fresh
 `## Unreleased` for the entry. Don't let git merge it into the released section, which it will
 do without a conflict, because the two sides touch different lines.
+
+That rule only helps if whoever propagates remembers to apply it, and the failure it prevents
+is quiet enough to miss. django-bootstrap4 watched it happen while cutting 26.3: rebasing the
+release branch onto a propagation PR filed that PR's two changelog entries at the foot of the
+dated section, no conflict raised. They belonged in that release, so the result was correct by
+luck. Git chose it, not a person, and nobody would have caught it had it been wrong.