Sync the release preflight from django-marina

[dyve]

Propagation of zostera/django-marina#694, where the reasoning lives.

just release-check hid most of the commits. It listed only commits touching src/, then closed with "Every commit above must be covered by an entry". That reads as a complete list and is not one, so anything tooling-only was invisible. It now prints a second group for commits touching nothing in src/, under a heading that says to read them rather than a rule, because no rule fits that group: a Dependabot bump of a dev dependency is genuinely nothing to a user, while a lint rule, a CI gate or a contributor policy belongs in the notes under tooling. Across marina, bootstrap4 and bootstrap5, roughly eighteen changes had gone unrecorded this way.

just build passed with a stale lockfile. uv sync --frozen does not check the project's own package version, so a bump could ship with the old version still in uv.lock while twine, check-manifest, pyroma and both smoke tests all reported green. Verified directly in marina: uv sync --frozen installed 26.9 against a lock naming 26.3 and exited 0. build now depends on a check comparing the two, which puts it in front of release-tag as well, and just relock regenerates the lock without upgrading anything (just upgrade bumps every dependency and has no business in a release commit).

MAINTAINING.md release steps 1 and 2 are updated to match. The justfile is byte-identical to django-marina again.

Verified with just lint, just build and just test-cov at 100%. just relock was a no-op here, so this repository's lock was already consistent.

Sequencing with #895

#895, the 26.4 release, is open. PACKAGING.md now says not to branch a propagation off a release branch, which is what produced the phantom 26.4 here in the first place, so this is branched off main instead and carries no release commit.

That leaves the merge order to settle, and either way works as long as it is deliberate:

• release: 26.4 #895 first. Then this needs a rebase, because ## Unreleased will have become ## 26.4 (date). I will add a fresh ## Unreleased for these two entries rather than let git file them under the released heading, which it would do silently since the two sides touch different lines.
• This first. Then release: 26.4 #895 should pull these two entries into its 26.4 section before it is cut, otherwise the release ships them unrecorded, which is the exact failure the first half of this change is about.

The entries are appended at the end of Unreleased rather than the top, so they do not collide with anything #895 prepends.

Credit where it is due: the lockfile half of this exists because the django-bootstrap5 session tested my claim that just build would catch a stale lock, instead of believing it. It does not, and did not.