[2/n] be more rigorous about when events are recorded in-memory vs durably

[sunshowers]

This fixes at least three different races, all related to #17.

Previously, the main executor loop and the worker task both updated parts of in-memory state separately. During this brief window of divergence, it was possible to observe torn state in a few different ways. See the included tests for some reproductions.

With this change, we make it so that:

• in-memory state is always changed by the executor loop, atomically (while the lock is held)
• durable state is always changed by the worker

For start events, in-memory state is updated before durable state. For completion events, durable state is updated before in-memory state. This seems like the most reasonable way to do things.

I had to introduce some additional injection infrastructure so tests can reproduce the races deterministically.

See the comments on #17 for detailed design discussion.