Why would that matter? The UEFI only sees the EFI System partition and its contents. There are regulated paths within that ESP where the UEFI may look for as of yet unknown executables (that is how USB sticks are recognized as EFI-bootable. By a FAT partition that contains /efi/boot/Bootx64.efi). UEFI can neither mount your Linux partition (at least it should not) nor does it need anything from it. The bootloader is on the EFI partition and has the job of finding all other partitions it needs and read from them whatever it needs to continue booting the OS of your choice.
CapsuleApp.efi is instructed to copy the capsule files to “THE” ESP partition. In the previous 3.08b EFI updater this was hardcoded to fs0, whatever fs0 happened to be on your system and it failed when fs0 was no ESP partition.
The 3.08d updater instructs CapsuleApp to choose automatically. CapsuleApp as an option -F to dump all ESP partitions it found and the one it chooses will be among them. Perhaps it does not recognize any of your partitions as valid for some reason or it recognizes more than one and is confused / makes the wrong choice. Creating an ESP partition on the USB stick itself should not be needed, as any sane system running from the NVMe should already have an ESP partition.
Whether the update works from an ESP behind a USB device, I do not know. It might not since that is not a typical use case. So I would suggest checking what ESP partitions CapsuleApp finds, to investigate further why the automatic choice might fail.
Edit:
Looking at the source-code of CapsuleApp (current master branch, so may be different if the CapsuleApp used was built from older sources) seems to base its automatic choice of ESP off of wherever bootnext points to. I think that should be your default boot option as configured in the BIOS. But if that makes the difference you may want to double check that.
Edit2:
Previous answer was incomplete. It does look at the bootnext option. But that is not typically expected to be set. In that case it iterates over all boot options for the first one that uses an ESP.
Oh, and the files are written to \efi\UpdateCapsule\
/Edit
You are aware that Framework has established a proud history of not meeting the various estimates that they gave for progressing a firmware version to release and yet remaining completely quiet and not even confirming any issue that is a blocker to a release? So calling this a “procedure” is a bit of an overstatement.
The last timeframe they announced for 12th gen was those 2 weeks for the 3.08 updater from January. And there were only crickets for months and then a hastily released version without announcement in this thread of the wrong installer. The 3.06 beta before stretched this uncertainty windows to like a year.
And I also believe I have shown that Framework’s release notes for firmware updates can neither be relied upon for solved issues nor for known issues. They only ever seem to reflect some arbitrary snapshot in time and are never kept up-to-date with what is actually known. So the first part of your post has also been disproven by Framework themselves on this very update…
