Release policy follow-ups: upgrade notices, rollback and breaking data changes #1896

Follow-up to #1870. These are the questions the release and support policy left open, so the policy itself can land without them.

Open questions

1. Upgrade notices in each release. Should every release carry a short notice for sysadmins saying whether it needs config changes or database changes, what to test, and how urgent it is (security, recommended, optional)? If so, is it written by hand at release time or generated from commit types and BREAKING CHANGE: footers? This also covers how a data-integrity fix states which versions were affected and what to check again, such as re-running an export.
2. Rollback. Is downgrading supported? If the answer is "restore a backup", the deployment docs need a backup step before every upgrade.
3. Breaking stored-data changes. The api uses MongoDB with no migrations, so a stored-data break in a new major has no defined way to reach existing databases: a migration at boot or a manual step in the upgrade notes. Deferred until the first such change is proposed.