0.13.1 — the migration creates its own column

The first `status` after deploying 0.13.0 showed twelve old events with the page language “none”. Migration `0013` had recorded itself as done, moved the view counters correctly, and left the events alone.

The cause is ordering. The `events.page_lang` column is created by the log module, but only on the first event write. The migration runs on the first view-counter read, which comes earlier. An `UPDATE` on a column that did not exist fell into a `catch` meant for a missing table, and nobody saw it.

The dress rehearsal on a copy of production passed because it ran in a different order: the database merge script created the column before the first page view hit the copy. The test checked the correct scenario and said nothing about the one that actually happened.

What changed

Filling in the events moved out of `0013` into a separate migration, `0013b`, which creates the column itself first. Databases where `0013` already ran get `0013b` on the next start. Both orders were checked for real this time: on a copy of current production and on a clean pre-0.13 database, with no script.

The rule from here on: a migration creates every column it touches instead of relying on which module happens to wake up first in the isolate.