Cannot access registries in container block entity "lock" field

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).