expand the downtime range from the time of the database failure

The argument here is that this shows up as "resolved in N hours", and we should be honest that the outage actually started when we started losing data.

Another way to put this would mark the upgrade time (2023-10-31) as the start of the outage, but I think that would be slightly less honest, as that's just when the service was visibly down: all data in the four days preceeding that are still lsot.

This MR also grew to include expansive cleanup and rewording.

See: team#41388 (closed)