The #bitlocker recovery screen was actually informative. It told me that the drive key had been sealed to an environment the previous night, and platform configuration register 7 did not match up on its 3rd update.
So right away I knew that windoze had performed an update, resealed the drive in a way that didn't match the current reality, and rebooted, locking away any record of what that update had been supposed to be

I disabled secure boot, booted a live Linux USB stick, and took a look at tpm2_eventlog. Took a long while, using the tpm2-tools repo for reference, before I could check the hashed for myself. Sure enough - PCR7 had a bunch of updates to its state, and the output of the 3rd one didn't match what #bitlocker was expecting.
Ok actually it diverged right from the start now, because I'd turned secure boot off. But I flipped a 00 to a 01, and ended up with the same wrong hash that bitlocker was complaining about.
Well, so now what?

That third update to PCR7 (actually the fourth, at index 3 because of 0-up indexing) was an EFI variable called "db" and luckily the structure definition is in the tpm2-tools repo. It's a list of authorised signatures. There were 6 in the list. I split them off into individual files and checked the hashes of the first 1, the first 2, etc.
If microslop had locked to an environment with a 7th and I was missing that signature, I'd be screwed.
Luckily, supplying just the first 5 signatures gave me the correct hash.
Even more luckily, my UEFI settings screen let me load this new file from a USB stick.
Even even more luckily, the laptop booted into windoze and I could decrypt the drive before another automatic update fucked things up again

@sleepfreeparent Wow, well done! I know who to come to if I have drive encryption problems! (I never encrypt my drives because a situation like this is my nightmare)