I believe the main issue that I had resided in the USG and not within the RUTX09. (I had set up a virtual interface on the LAN port which resulted in martian source errors from the arp packets from the RUTX09, and this seemed, as far as I could tell, to periodic failures, about every 30s or so - this is still a mystery to me). I believe I now have a working system which I will summarise here for those that follow....
1.1 Set the mobs1a1 interface to passthrough mode and enter the mac address of the USG.
1.2 Configure the LAN interface with a static IP address (In my case 192.168.5.1, mask 255.255.255.0, gateway 192.168.5.2, broadcast 192.168.5.255, DNS 192.168.2.5 (pi-hole on a pi).
1.3 Enable the LAN interface DHCP server.
1.4 Configure a static route for the lan interface to target 192.168.0.0 (because I have other subnets in this range beyond the USG), mask 255.255.0.0, gateway 192.168.5.2.
1.5 Setup a manual entry in the arp table using "ip neigh add 192.168.5.2 lladdr xx:xx:xx:xx:xx:xx dev br-lan" where the x's are the mac address of the USG, the same as in the bridge setup. (The reason for this is that in this scenario 192.168.5.2 doesn't actually exist in the USG and so it can't be arp'd).
2.1 Setup the WAN port for DHCP (not ppoe as I had anticipated from having previously setup adsl modems). This picks up, in my case, the 10.x.x.x CGNAT dynamic ip address from the mobile operator.
2.2 Setup a static route for 192.168.5.0/24 to the USG WAN interface.
2.3 That's it in this scenario. I have NOT configured 192.168.5.2 using a virtual/pseudo-ethernet interface as it isn't necessary.
So in the RUTX09, the 192.168.5.2 gateway address is just used to get you to the manually entered mac address of the USG in the arp table. This seems to me to be a very unconventional way to configure this pair of interfaces, but it side-steps the martian source problem in the USG, which I was unable to find a solution to.
I believe that's it. Problem solved, sort of.