Currently I have bitlocker set up on windows, which I do prefer to have, but sometimes changes that linux makes to the system trips bitlocker and causes it to need the recovery key
Avoid booting Windows from within Linux GRUB, because the system state BitLocker uses to seal the key with your TPM depends on the entire boot chain – going through GRUB means any grubx64.efi upgrade is going to make the key unsealable.
So instead, either use your firmware's F8 menu (or F11, or F12...) to select Windows BOOTMGR without going through GRUB, or use efibootmgr from Linux to ask the firmware to "please reboot directly into Windows next time" (see here and here).
On top of that, enabling Secure Boot would allow BitLocker to bind to PCR7, which is less fragile when dealing with Windows BOOTMGR updates too. (Avoiding GRUB is a prerequisite for taking advantage of PCR7 sealing; BitLocker will refuse to use it if it detects anything non-Microsoft-signed in the chain.)
Is it possible to unlock it through a file saved on a USB stick? And I don't just mean putting the key onto a stick and typing it in from that
Probably, yes, it's a built-in feature of BitLocker, but from what I remember, it expects a differently-formatted key; i.e. you can't just put the numeric recovery key in the text file; you'll need to add a new keyslot ("key protector") for that.
Try to use manage-bde -protectors -add -RecoveryKey to create the key file on your USB stick (e.g. assuming it's mounted on H:\):
manage-bde -protectors -add C: -rk H:\
Note: You do need the full version of BitLocker for this (i.e. "Device Encryption" found in Windows Home won't do). I don't actually know whether BitLocker allows the combination – although there's no good reason it shouldn't, but I recall it gets picky sometimes.
Side note - is there a way to look through logs somewhere and find out what exactly triggered bitlocker to need the recovery key? I think I know what it was this time but I'd like to be sure.
It's technically possible, but it won't be BitLocker logs – you'd be looking at the TPM's "TCG Event Log", and you would have to compare it against an earlier log from a "known working" log. (That's because it is not a "things went wrong" log – it's more of a "system state audit" log that the TPM PCRs are computed from; changes in this log influence whether the TPM will agree to unseal the BitLocker key or other data.)
The log file is in a standard TCG-defined binary format and is stored in the firmware's RAM; Windows helpfully dumps it in a .log file under C:\Windows\Logs\MeasuredBoot (logs from earlier boots collect there so you can compare them), Linux allows reading it via /sys, and there are tools to decode it from binary format into some form of textual log (I wrote one for myself when investigating this kind of BitLocker issue); starting with the one Microsoft recommends might be a good idea, but there is also a PowerShell module, tpm2_eventlog on Linux, tcglog-parser, etc.
(Windows' own Event Log does tell you whether BitLocker seals its key to PCR7 or PCR4+etc – without Secure Boot it's the latter – and I'm 80% sure that changes in events marked for PCR4 are the cause, as PCR4 events primarily deal with recording the exact SHA hashes of every bootloader involved in the process, such as grubx64.efi from your Linux install.)
