Follow-up from "Make Geo::PruneEventLogWorker delete rows more gently"

The following discussion from !5835 (merged) should be addressed:

Right, I'm just imagining a scenario:

  • Someone accidentally deletes the GeoNode entry from the database.

  • Geo secondary is at event X with n rows behind

  • The cron worker drops all the rows

  • Admin re-adds the GeoNode entry for the secondary

  • All events between X and n are now lost

This does seems like a corner case since the cron job will run on average 12 hours after any DB changes, but just wanted to raise it because it seems like we might want to defer removing the whole table some time after the database changes have settled.

We could do this fairly easy with a perform_after.