This manual vote request only happens if the node is shut down while a fork is being negotiated and doesn't see the final conclusion. Because it's a lattice, it's only affecting the one account that intentionally created the fork, the rest of the chains are unaffected.
And if that one account had sent a lot of transactions which, say a large proportion of recipient accounts then built upon, it surely affects more than just that one account in total?
Right, it could affect more accounts, accounts that received from the fork that was just outvoted, they're all invalid. The issue is, if the local node that's synchronizing didn't see the final vote for this block by virtue of the fact that we have it locally but the network voted against it, that indicates those derived blocks didn't wait for proper confirmation indicating they're actually in collusion on the fork.
If receivers wait for vote confirmation on a block before receiving it they have no chance of their chains being rolled back.
Partition tolerance, yes, partition detection is different though. With voting if I'm getting votes that sum to 15% of total supply, the network is split. With hashing if I'm getting a 1Mh/s rate is the network split? Maybe. I can guess if I know and trust an expected hash rate.
That only makes sense if you know what percentage of total stake is supposed to be voting at any one time.