I didn't think the system reset would work: this is weird private data that would be covered oddly by any resets. I saw somebody else manually delete those Lock Screen folders and got it to reset upon the recreation... that might be a better path to solution.
I'd like to get to the bottom of this and fix it. I would need physical access to a machine in this state and want to put it under a kernel debugger and go from there. Besides that, actual support (I'm a developer, not part of support) would need to do about that equivalent. It's probably not an easy thing to diagnose abstractly, as has been noticed. People still hitting this that need answers probably need to turn to actual product support. I don't know if actual deep product support is available on this forum.
The permissions on that directory are very serious and not generally meant to be ever be tampered with by a user because it's in a more secure zone (the lock screen). This is by design. Those locked down permissions were apparently corrupted in some fashion on your system. Having the system be more resilient to that corruption would be excellent, but since I for one don't have a full understanding of your system state it would be hard to know how to recover from that if applicable. Either bashing it yourself or getting it into the hands of actual support are probably the best way to move forward here. :\
If my system were still in that state, I would not mind doing that.
Microsoft developers and support personnel do read these threads from time to time.
The trouble with the current configuration in security made it impossible for the system to change the lock screen settings for the lock screen or even see what is already there when the problem occurs. I don't understand the logic in giving system rights to only TrustedInstaller and preventing SYSTEM from accessing folder contents.