From the behaviour it looks like, on world load, a house's locked-slot list isn't replaced but added on top of whatever the object already holds in memory. If a house record gets applied to an object that already has that locked slot, the list doubles. The next save writes the doubled list back. And so on every restart, until the file hits 2 GiB and dies.
What you can see in the file and in backups:
1. Only rebuilt Land_House_* houses with a combination lock attached and locked are affected. Where there's only a digital code lock, it's clean, the locked-slot list is empty. That makes sense: a code lock blocks its own removal, while a combination lock locks the slot on the parent, i.e. on the house.
2. In an affected house's record the name Att_CombinationLock<N>_<Wood|Metal> comes in a batch, and the count in front of it is exactly the number of repetitions. And it's always a power of two.
3. It grows by the same factor every restart, no players needed for it. For those whose house is stored 4 times in the DB, the factor is x4 per load.
4. If you take the lock off in-game, the growth stops for that house. If you clean the file by hand (keep the unique names, fix the count), the server loads fine and the structures are intact. So the data itself is okay, it's the load/save handling that breaks.
As it is:
the old stays, the new gets appended, the list grows on every load, the record grows on every save, building_001.bin crosses 2 GiB. After that _EOF isn't written, and everything in the file after the affected object is lost. Hence the lost structures people are getting (https://report.bistudio.com/issues/DZG-1404, https://report.bistudio.com/issues/DZG-1440).
Aside:
why a house is stored 4 times in the DB in the first place I'm not touching here, that's a separate question. But the append-instead-of-replace on its own is already enough for the list to grow without bound, as soon as a record lands on an object that already has the slot.