If the ceph-osd config does not match the actual layout of an machine, the charm should not execute the lvm related part of the disk setup.
In this occurrence the bluestore-wal and bluestore-db where configured to the 'wrong' partition on an nvme.
While this was the case the charm still configured all the osd's with encryption, pv's, vg's, and lv's.
Once the error was found and corrected, the charm got blocked, complaining that it could not find any pristine disks, which is to be expected as those where already configured by the charm itself, but the osd configuration could not finish as the bluestore related setting where wrong.
That these settings are wrong does happen from time to time in practice with expansion of clouds when the new machine's cannot be configured exactly the same and during the inital phase maas was not setup to use labels for the bluestore-wal and bluestore-db entries (something that is common).
I think it would be reasonable for the charm to go into a block state if the wal and db configuration options are populated, but the devices don't actually exist on the unit being used.
This would avoid just the block device part being created and used for the OSD.
As these options are whitelists its possible you won't get an exact device match for every device, but we could at least do a >= 1 of type check to validate this.