Well, you're going out of your way to make it not work 
The approach relies on this:
When you add the route "159.148.147.251/32 via vlan2@vrf-wwan" (I'm guessing here), you force source address selection to select 135.180.131.119. (Source address selection happens at 16 in this chart The ultimate Mikrotik iptables flowchart) BUT: this address is not in local.
The intended packet flow is:
- source address selection happens according to a normal route and the selected address is in local (let's say 192.168.111.1)
- mangling occurs, redirecting the packet to vlan2-wwan (but the source address is not modified in the routing adjustment stage)
- postrouting src-nat occurs, making the packet signature (192.168.111.1->135.180.131.119)->159.148.147.251
- the response packet is translated back by connection tracking 159.148.147.251->(135.180.131.119->192.168.111.1)
- the packet is redirected by the mangle prerouting rule to main
- the address 192.168.111.1 exists in local
- the packet is received
So... by simply choosing any interface as the target for your route to 159.148.147.251/32 where the router has an address that is populated in local, you will succeed.
Just another thing to consider. I see (and I'm glad to see) that your packet capture is about the https connection. Ping works strangely, because ICMP reception happens a bit differently to other packets, and therefore using ping to troubleshoot issues regarding vrfs can quickly veer you off course.