Can you assume the reactor has durable, local storage with atomic transactions?
The answer is to model your design and use a sufficient level of rigour in validating that your system meets your requirements.
Maybe you could use a database server that has the right properties to ensure your reactor could survive a restart.
What if you want to add multiple reactors so that you can process an event stream with a high volume of events, faster?
It's the same problem as presuming that ACK messages in message brokers/queues are guaranteed to not fail.
Since the message transport and other durable resources are rarely able to be enlisted in the same atomic transaction, and since distributed transactions would largely be an antipattern, it would seem that a reactor that records its current position can't be presumed to be an infallible way of ensuring that messages aren't processed more than once.
In the end, it always comes back to ensuring that handlers are idempotent, having something that can be used as a stable and consistent idempotence key, and accepting that the idempotence logic is the responsibility of the handler coders rather than something we can count on generalized infrastructure for.