I was a bit surprised when I checked the docker docs that there’s no mention of NAT for the bridge network driver, because that’s what’s happening.
Within your server, between the docker-bridge and your physical (and virtual wireguard) interface is a router which performs NAT (Network-Address-Translation). As a matter of fact, it’s likely happening again on the other side of the wireguard tunnel, since you’ll probably end up sharing the public IP with other ProtonVPN customers.
It’s exactly the same mechanism your internet-router uses who likely only has a single public IPv4 Address. When you open a TCP connection from your computer, the router will store the combination of (src-ip, src-port, dst-ip, dst-port) into the NAT table and rewrites the src-ip to the public IPv4 address. Once a reply packet comes from the destination, it will look into its NAT table and if it finds a match, it’ll rewrite the dst-ip to your personal machine.
This whole process can also happen twice or more times without issue. (Initiating connections from outside to inside becomes a problem though, that’s why Port-Forwarding exists).
The wireguard tunnel might add to the confusion, but see it as a separate connection that needs to be established. Once the tunnel is made, all traffic flowing through the tunnel does not need to be aware of anything underneath the tunnel.
A diagram of the relevant Hypervisor/VMs/containers + Network information would be helpful.
From where and how are you testing DNS? Did you use dig and specified the nameserver directly?