Make the changelog's breaking list match what actually breaks

[matasarei]

The 3.0 changelog listed five breaking changes. Checked each against the 2.3 tag; three are
not breaking, and the changelog was missing a fourth behaviour change that matters more than
any of them.

What was wrong

Listed as breaking	Actually
Access by capability, not site admin	A widening. 2.3 gated on is_siteadmin(), and an administrator holds every capability, so nothing an admin could do stopped working. What changed is that managers gained read access — worth a deliberate revoke, not a break
cli/cleanup.php reports unless given --execute	The script is new in 3.0. There was no bare command whose behaviour could change
The cleanable component list starts empty	Behaviour is preserved exactly. 2.3 hardcoded assignsubmission_file and backup and ran them only when autoremove was on — precisely what the upgrade seeds. A site with it off deleted no component files before and deletes none now

Verified from git show 2.3:classes/task/cleanup.php and 2.3:files.php, not from the plan.

What it says now

### Breaking keeps the two that genuinely break code: the settings namespace move and the
step class renames.

### Upgrade notes is new, and carries the three above plus one the changelog never
mentioned: unlinked files are not removed for the first ghostgracedays after upgrading.
The two new columns are not backfilled, so the first scan after the upgrade counts as the first
of the two sightings that must agree. An operator watching the list stop shrinking will read
that as a regression unless something says otherwise — it is the single most likely support
question this release generates.

The release notes said "five breaking changes" and now agree with the changelog.

Testing

Documentation only — no PHP changed. Verified the release-notes extraction still selects the
right block: 104 lines, sections Breaking, Upgrade notes, Security, Fixed, Added, Changed, no
bleed from the 2.3 entry.

Notes

• The published 3.0 release body is generated from .github/release-notes/3.0.md, not the
  changelog, so it does not need re-cutting for this — but it is now out of date by one
  sentence. Re-pushing the tag after merge would refresh it if that is worth doing.