v4.2.1

A republish. Core has no changes of its own.

Fixed

• BarakoCMS.ExternalAuth, BarakoCMS.Files and BarakoCMS.Portability are published at
  4.2.1. The 4.2.0 release pushed all three at 4.1.1, a number none of them had been published
  under before, so nothing was skipped: the 4.1.1 packages already hold the 4.2.0 work, the OAuth
  state from RandomNumberGenerator (#754, closes #652), the corrected Files documentation
  (#748, closes #553) and the 200-field cap in Portability (#861, closes #650). What was wrong is
  the number. A module's version is the version of the release that publishes it, and
  scripts/check-module-versions.sh measures that against the v<version> tag, which did not
  exist until the release created it, so the check passed on the release pull request and went red
  on the next one. 4.2.1 republishes the three under the version they should have carried; the
  code is the same as 4.1.1. Unlike 3.12.1, 3.17.1 and the 4.1.0 Import and Portability skip
  (#749), no change was lost this time. The first version of this entry said --skip-duplicate
  had dropped them. It had not.
• A deploy carrying a schema change the target database will not accept is refused before the
  running container is replaced. Production and playground run AutoCreate.CreateOnly, which
  creates a missing table and never alters an existing one, so a release carrying a delta on a table
  that is already there throws on start and crash-loops with the previous container already gone.
  4.2.0 did exactly that on playground. db-assert was on the image and in the 4.0 upgrade guide,
  but nothing in the deploy path ran it. The production upgrade doc now puts it between the pull
  and the up, scripts/assert-schema-current.sh is that step for any compose stack, and the
  playground deploy script on the host runs the same check before it recreates the app. The doc
  also said "schema migrations run on start", which is true for a new table and not for a changed
  one, and now says which is which.