I didn’t read the rest fully, and I certainly don’t know what happened to you, precisely. I just want to note for posterity that restoring the database to some older point in time isn’t something you can expect to work, in general.
To begin with you need to be very sure that the dataset you restored matches the corresponding database state at the same time, precisely. If it does not, the changes from the database-described state can only be assumed to have happened since last scan. That is, if you restore the database from time T and the files from time T-1 and a file was created in that interval (and recorded in some later database version), it will look like it was deleted. (It’s present in the database but not the files on disk.)
Even if your files and your database match exactly from the same point in time … the second issue is that Syncthing doesn’t send the whole database every time it connects to another device. Instead we only send changes that have happened since last connect, based on an in-database sequence number. If you rewind that number there are now a bunch of changes you’ve sent to other devices but are no longer aware of yourself. Those peers will think you have a different set of files than you actually do. Changes you make now will also get assigned “old” sequence numbers and might not get seen by peers, because they already have the corresponding updates (they think). (There is code in place to handle this situation somewhat, but it’s not foolproof, and can’t easily be.)
This is also a situation we don’t test for. At all. So there might be further dragons lurking.