According to your first logs, your system was put to sleep in that boot process, and kept asleep for about 5 hours:
Feb 13 13:56:51 systemd-sleep[6895]: Successfully froze unit 'user.slice'.
Feb 13 13:56:51 systemd-sleep[6895]: Performing sleep operation 'suspend'...
Feb 13 13:56:51 kernel: PM: suspend entry (s2idle)
Feb 13 13:56:51 kernel: Filesystems sync: 0.017 seconds
Feb 13 18:54:57 kernel: Freezing user space processes
If you are sure it was not, these logs indicate an issue, but I have to admit, I tend to assume these entries are reliable 
That’s again a long log of 36 minutes, but it’s ok to skim. I don’t think it is the cause of your problem, what it makes me wonder that your clock has been massively adjusted during the test?
Feb 07 01:00:44 chronyd[1389]: Selected source 192.168.178.1 (_gateway)
Feb 07 01:00:44 chronyd[1389]: System clock wrong by 760985.103617 seconds
Feb 15 20:23:49 systemd-resolved[1325]: Clock change detected. Flushing caches.
Feb 15 20:23:49 chronyd[1389]: System clock was stepped by 760985.103617 seconds
Feb 15 20:23:49 chronyd[1389]: System clock TAI offset set to 37 seconds
Formally, the boot started at exact 01:00:00.
Can you try to unplug everything that is attached by USB and then try again? I ask because of the time delay’s that occur here:
Feb 07 01:00:02 kernel: typec port0: bound usb4_port1 (ops connector_ops [thunderbolt])
Feb 07 01:00:04 kernel: usb 3-2.3.2: New USB device found, idVendor=046d, idProduct=0843, bcdDevice= 0.13
Feb 07 01:00:04 kernel: usb 3-2.3.2: New USB device strings: Mfr=0, Product=2, SerialNumber=1
Feb 07 01:00:04 kernel: usb 3-2.3.2: Product: Logitech Webcam C930e
Feb 07 01:00:04 kernel: usb 3-2.3.2: SerialNumber: 4DADC45E
Feb 07 01:00:15 kernel: usb 3-4: new full-speed USB device number 10 using xhci_hcd
Feb 07 01:00:15 kernel: usb 3-4: New USB device found, idVendor=3434, idProduct=0661, bcdDevice= 1.00
Feb 07 01:00:15 kernel: usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 07 01:00:15 kernel: usb 3-4: Product: Keychron Q6 Pro
Feb 07 01:00:15 kernel: usb 3-4: Manufacturer: Keychron
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/0003:3434:0661.0005/input/input15
Feb 07 01:00:15 kernel: hid-generic 0003:3434:0661.0005: input,hidraw4: USB HID v1.11 Keyboard [Keychron Keychron Q6 Pro] on usb-0000:00:14.0-4/input0
Feb 07 01:00:15 kernel: hid-generic 0003:3434:0661.0006: hiddev98,hidraw5: USB HID v1.11 Device [Keychron Keychron Q6 Pro] on usb-0000:00:14.0-4/input1
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:3434:0661.0007/input/input16
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:3434:0661.0007/input/input17
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:3434:0661.0007/input/input18
Feb 07 01:00:15 kernel: input: Keychron Keychron Q6 Pro Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.2/0003:3434:0661.0007/input/input19
Feb 07 01:00:15 kernel: hid-generic 0003:3434:0661.0007: input,hidraw6: USB HID v1.11 Mouse [Keychron Keychron Q6 Pro] on usb-0000:00:14.0-4/input2
Feb 07 01:00:27 systemd-cryptsetup[636]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/4a3d4c2d-6b91-4543-be49-ef9c869f3dcd.
Feb 07 01:00:31 systemd[1]: Found device dev-disk-by\x2duuid-8b3be73f\x2d77bd\x2d4dc0\x2d9efd\x2dd1578d945c55.device - /dev/disk/by-uuid/8b3be73f-77bd-4dc0-9efd-d1578d945c55.
Feb 07 01:00:31 systemd[1]: Finished systemd-cryptsetup@luks\x2d4a3d4c2d\x2d6b91\x2d4543\x2dbe49\x2def9c869f3dcd.service - Cryptography Setup for luks-4a3d4c2d-6b91-4543-be49-ef9c869f3dcd.
Feb 07 01:00:31 systemd[1]: Reached target cryptsetup.target - Local Encrypted Volumes.
I could imagine these are your 30 seconds?
I did not read everything of the 36 minutes, but the term “fuse” seems to not occur at the time the delay occurs, and the time the delays in the logs occur correspond to your elaborations about when it occurs.
This is not a solution per se. But I think it tells us where to focus on. But again: this can itself be a symptom of an earlier cause. But it’s something worth to analyze.
It might be useful to compare: you say that the issue came after an update. However, have you ever tested to revert? So if you know boot your earlier Silverblue image from before the update, does it still boot fast without the delay? Is that 100% reproducible? Old image → quick boot and new image → <=30 sec delay? If so, it might be useful to compare a log of both…
You might also check out the log lines of the time of the delay in your preferred search engine and see if others link these lines to comparable phenomena.
Maybe someone has also time to analyze these logs in depth but that might take some time