That final (or rather: initial) lookup via a root server also looks OK.
For your unbound configuration, my intention was to verify whether your unbound may have been configured to prefer IPv6, which could have explained failures, given Vodafone's obvious lack of IPv6 support for your LTE connection.
But those related options are both turned off (just as our guide recommends):
But then, your unbound configuration reveals a peculiar extra in a separate, non-Pi-hole configuration file:
Instead of doing the recursion itself, this would have unbound forward all DNS queries to 80.69.96.12 and 81.210.129.4, which happen to be Vodafone DNS servers.
Any ideas how those came to be part of your config?
Given that they are Vodafone, and that is also your LTE provider, I'm not yet convinced it should have an impact on your observation, but:
If you didn't add those entries yourself for a reason, I'd give removing them a try.
Ah, I see now where that would have come from - on Bullseye, the combination of resolvconf and unbound may leak host DNS settings into unbound's configuration.
Please apply:
Edit file /etc/resolvconf.conf and comment out the last line which should read:
EDIT:
The strange thing here is that this would have affected DNS resolution regardless of a DSL or LTE connection, as that unintended unbound configuration would always have been active.
It's even more strange that this did only corrupt your fallback connection via Vodafone LTE, as the upstream servers that have handled DNS requests would have been 80.69.96.12 and 81.210.129.4 - Vodafone Kabel's very own DNS servers.