If a migration fails on the first batch it doesn't save that failed state to the DB

When a migration fails on the first batch, it returns the failure but doesn't persist the failure to the database.

This can be confusing when it wasn't started directly by a user, as the failure isn't apparent when you ask for the status - it's either not there, or showing results from a previous run.

The tradeoff is that we could always persist the start of a migration but do no work in the first mutation, but then when you run it directly you won't see the immediate failure (because it will happen in a scheduled function).

I currently think it's more helpful to see the failure of the first batch, at the cost of not having a record of it.

### Why not fail and persist?

We could catch the failure and then persist, but catching the failure doesn't roll back the failure's changes.

Potential workaround: we could use `runMutation` to run a sub-transaction that could fail and roll back, but the outer transaction can catch that and persist the failure, without accidentally committing the sub-transaction's changes. 💡