grub still tries to mount cryptodisk by its old UUID after changing it

I have a Linux system with the following disk setup (MBR-formatted, BIOS-booted):

sda                                             32G disk              
└─sda1                                          32G part  crypto_LUKS 001b349b-2a70-4408-bae2-107d035c96e9
  └─luks-001b349b-2a70-4408-bae2-107d035c96e9   32G crypt btrfs       8c72adab-63cf-4526-b77e-78f11d2585e2

It works great, but I want to change the UUIDs of both the LUKS volume and the filesystem. This is because I am creating a bootable rescue USB off my main machine, and so I need to avoid UUID collisions when booted from the USB. So I try:

sudo sed -i 's/001b349b/101b349b/g' /etc/default/grub
sudo sed -i 's/001b349b/101b349b/g' /etc/fstab
sudo sed -i 's/001b349b/101b349b/g' /boot/grub/grub.cfg
sudo sed -i 's/8c72adab/7c72adab/g' /etc/default/grub
sudo sed -i 's/8c72adab/7c72adab/g' /etc/fstab
sudo sed -i 's/8c72adab/7c72adab/g' /boot/grub/grub.cfg
sudo update-grub
sudo grub-install /dev/sda --modules=btrfs

Once done, I attach the disk to another machine and adjust both UUIDs:

sudo cryptsetup luksUUID /dev/sda1 --uuid "101b349b-2a70-4408-bae2-107d035c96e9"
sudo btrfstune -U 7c72adab-63cf-4526-b77e-78f11d2585e2 /dev/mapper/sda1-crypt

When I try to boot from the resulting disk I see:

error: no such cryptodisk found.
error: disk 'cryptouuid/001b349b2a704408bae2107d035c96e9' not found.
Entering rescue mode...
grub rescue> _

That said, *somewhere* the old LUKS UUID is still sitting. I expected it to be overwritten with the new one when I ran grub-install, but it didn't happen. Why is grub still trying the old UUID? What am I missing to make it try the new one? UPDATE: It appears that when grub-install is run, it possibly takes the old UUID from the currently mounted LUKS device (as opposed to from any config file) because I can't see where else the old UUID could come from. Is this what happens? Is there any way to override this behavior?