So all said and told here, any given user trying to reconnect after a long time during the attack window has a 3 in 10 trillion chance of being successfully duped without an alarm being raised. And those aren't the only fractions at play. The number of users trying to reconnect after a long time during the attack window is probably pretty tiny as well.
In any case, the one item up there that opens up a further attack opportunity is item 11. An attacker could create malcious public nodes that act like honest nodes until they're asked what their snapshot is by a new connection. When asked, they give some nonsense snapshot hash. A small number of public nodes could cause a bit of chaos. But that chaos could only affect applicable reconnecting nodes that would need to go through the above process. So what nodes are those exactly?
Well, the attack is only cheaper than a normal 51% attack when the attacker can obtain old addresses that used to contain coins cheaper than they can contain actual coins. In VPoS, the randomness that decides who can mint is hidden for a period of time and is afterward active for a period of time. If the period of time that the randomness is hidden for is longer than the frequency at which new checkpoints are released. A 1 year timespan seems reasonable for both.
So because that possibility can be closed off, the other history attack possible is a longer-range history attack from before the checkpoint - which requires tricking users into accepting a malicious checkpoint. So the attacker might attempt to obtain addresses that contained coins a year ago (but no longer do). However, the only nodes that could even potentially fall for this trick are ones that have been offline for over a year. How many nodes go offline for that long? Probably almost none. But whatever that number is: that's the number that must go through the above process and that's the number that could be griefed by a malicious actor that releases fake data in step 11 above.
These steps do hinge on "raising an alarm" being sufficient to prompt people to do some deeper digging as to what chain is the right one. This could be as easy as calling up some trusted friends and asking them to read out a hash to you from their software. It could be asking the merchants you deal with most often, or your employer. I'd argue that similar steps to the above would be incredibly valuable to add to the bitcoin software upon update, since similar issues can happen if you install malicious softare (worse issues really).
There are also other mitigations that wouldn't stop an immediate attack, but would help prevent the attack from scamming a user for a long period of time. If successful, the attacker could simply mirror all transactions from the normal chain on their malicious chain. So the victim could get paid and pay honest people, but the attacker could be paying the victim for things with just fake coins on the malicious chain. However there is an idea that has been discussed before of putting a recent block hash in the transction, so that transctions are pinned to a particular chain and the attacker can't build a malicious chain with honest transactions. If transactions required recent block hashes, the victim would be alterted to the malicious chain as soon as they tried to pay someone honest or get paid by someone honest.
But I think there are still some things to clarify, since I may have not correctly understood a couple items in your attack scenario.
So all said and told here, any given user trying to reconnect after a long time during the attack window has a 3 in 10 trillion chance of being successfully duped without an alarm being raised. And those aren't the only fractions at play. The number of users trying to reconnect after a long time during the attack window is probably pretty tiny as well.
In any case, the one item up there that opens up a further attack opportunity is item 11. An attacker could create malcious public nodes that act like honest nodes until they're asked what their snapshot is by a new connection. When asked, they give some nonsense snapshot hash. A small number of public nodes could cause a bit of chaos. But that chaos could only affect applicable reconnecting nodes that would need to go through the above process. So what nodes are those exactly?
Well, the attack is only cheaper than a normal 51% attack when the attacker can obtain old addresses that used to contain coins cheaper than they can contain actual coins. In VPoS, the randomness that decides who can mint is hidden for a period of time and is afterward active for a period of time. If the period of time that the randomness is hidden for is longer than the frequency at which new checkpoints are released. A 1 year timespan seems reasonable for both.
So because that possibility can be closed off, the other history attack possible is a longer-range history attack from before the checkpoint - which requires tricking users into accepting a malicious checkpoint. So the attacker might attempt to obtain addresses that contained coins a year ago (but no longer do). However, the only nodes that could even potentially fall for this trick are ones that have been offline for over a year. How many nodes go offline for that long? Probably almost none. But whatever that number is: that's the number that must go through the above process and that's the number that could be griefed by a malicious actor that releases fake data in step 11 above.
These steps do hinge on "raising an alarm" being sufficient to prompt people to do some deeper digging as to what chain is the right one. This could be as easy as calling up some trusted friends and asking them to read out a hash to you from their software. It could be asking the merchants you deal with most often, or your employer. I'd argue that similar steps to the above would be incredibly valuable to add to the bitcoin software upon update, since similar issues can happen if you install malicious softare (worse issues really).
There are also other mitigations that wouldn't stop an immediate attack, but would help prevent the attack from scamming a user for a long period of time. If successful, the attacker could simply mirror all transactions from the normal chain on their malicious chain. So the victim could get paid and pay honest people, but the attacker could be paying the victim for things with just fake coins on the malicious chain. However there is an idea that has been discussed before of putting a recent block hash in the transction, so that transctions are pinned to a particular chain and the attacker can't build a malicious chain with honest transactions. If transactions required recent block hashes, the victim would be alterted to the malicious chain as soon as they tried to pay someone honest or get paid by someone honest.
But I think there are still some things to clarify, since I may have not correctly understood a couple items in your attack scenario.