The age of update heuristic is likely a good start; high profile vandalism like this is likely to be noticed in a reasonable amount of time. Vandalism in low profile areas is going to be harder to find though.
I'm pretty sure you can get a stream of all the changes, so you would need to do something like have one copy of the database where you processed updates in near real time, and a second (production) copy where you had a delayed replication stream; in that stream, you'd want to look ahead at the real time database to calculate your stability heuristic.
Alternatively, you could have the realtime database also populate a changed object queue -- anytime an object is changed pull it out of the middle of the queue and place it at the end again. If it makes it to the front, pull the current object data and place it in your production database.
This should help with vandalism, but you do run the risk of accepting only parts of a coordinated edit of several objects. You could consider simply stopping replication into your production database in case anything ends up ultimately unstable, but I suspect it's hard to find a point in time where everything edited before was not edited again in the next 15 days (or whatever your threshold is).
This is definitely a complex problem to solve, especially since you would want to have some escape hatches so your changes happen quickly, or you could flag upstream changes to apply quickly, or worst case, you might want to revert to an earlier version of the database.
If you can figure out how to divide the data into different regions, you might have better luck, but sometimes object ids are moved around quite a bit. Geodata is already messy, and having a multitude of editors doesn't help with consistency etc.