The new lock field on container block entities stores an item predicate, but when placed as a block, the block entity decoding fails when the item predicate contains any registry/holder information.

How to reproduce:

1. Give yourself a chest with the lock component

   /give @s chest[lock={items:"minecraft:anvil"}]
   

2. Inspect the given item

   /data get entity @s SelectedItem
   

3. Notice that the command was valid and that the full lock component is present on the item
4. Place the chest down
5. Notice that at this point you can only open the chest when holding an anvil, as expected
6. Inspect the chest's block entity data

   /data get block <coords>
   

7. Notice that the lock field is not present on the block entity
8. Re-enter singleplayer for the block entity to lose its lock data during deserialization
9. Notice that you can open the chest even when not holding an anvil
10. Repeat the same experiment with a lock predicate that isn't using registry access

    /give @s chest[lock={count:4}]
    

11. Notice that after placing this chest, even after relogging, you can only open it when holding an item stack with count 4

Code analysis:
The reason that decoding the lock field fails is that LockCode#fromTag uses CODEC.decode(NbtOps.INSTANCE, ..), specifically it uses the default NbtOps instance. In contrast, the vault block entity for example constructs a DynamicOps using holderLookupProvider.createSerializationContext(NbtOps.INSTANCE).