You actually have two problems 
When doing multi-wan, you should really study the packet flow diagram meticulously. A version of it is given in the Mikrotik docs, but this is often more suitable:
https://stuffphilwrites.com/2014/09/iptables-processing-flowchart/
As you can see, for locally originates packets (your ping) the “mangle prerouting” chain is never consulted (as documented)
The other is wrt wireguard. Wireguard has a bit of a strange behavior in that it selects the source address for its packets based only on the main routing table. (As is quite clear from the diagram referenced.) And thus while routing is altered as a result of mangling later (and your packet is transmitted on the intended interface), its source address is incorrect.
This can be helped with some … ahem … creative natting. The good news is that this behavior in your case is to your advantage. If you only use a singe wireguard connection, that will automagically continue on in case of a failover using your WAN2. The transition will happen within the wireguard persistent keepalive time (or if any traffic is sent into the tunnel on your side).
As a side note. I did some quite involved digging around the “wireguard and mangling/routing” issue, and while the original writers of wg maintain that their solution works as intended, other say quite plainly that it “was rushed into the kernel when it wasn’t ready”, i.e. it did not consider all scenarios.
Actually the normal linux implementation has a not-too-bad behavior around this, in that a wireguard interface can have an “fwmark” attribute attached (which means: tag all underlay outgoing packets related to this interface with this), and that can be matched in the routing rules. Mikrotik neither supports the wg fwmark, nor the matching it in routing rules behavior. (They referenced some time ago that “some solution” is on the roadmap. This is a very common question on both Mikrotik and general linux forums all over.)