using multiple tables to route ips from TWO ISPs

The routing configuration you show in your question looks like a substantial part of the solution. In order to test things out, I put together a simulation of your environment using Kathara; you can find my complete test environment here. The test topology looks like this:

The goal is that we can reach remotehost from nodes on the right (node00 through node11), and each node will use the appropriate outbound path from router.

The router node in this diagram corresponds to the system you are trying to configure. It has the following interface configuration:

161: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 111.11.111.2/28 scope global eth0
       valid_lft forever preferred_lft forever
    inet 111.11.111.11/28 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 111.11.111.12/28 scope global secondary eth0
       valid_lft forever preferred_lft forever
169: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 222.22.222.10/29 scope global eth1
       valid_lft forever preferred_lft forever
    inet 222.22.222.11/29 scope global secondary eth1
       valid_lft forever preferred_lft forever
    inet 222.22.222.12/29 scope global secondary eth1
       valid_lft forever preferred_lft forever
170: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.10.1/24 scope global eth2
       valid_lft forever preferred_lft forever
171: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.20.1/24 scope global eth3
       valid_lft forever preferred_lft forever

The following default routing table:

root@router:/# ip route
default via 111.11.111.1 dev eth0
111.11.111.0/28 dev eth0 proto kernel scope link src 111.11.111.2
192.168.10.0/24 dev eth2 proto kernel scope link src 192.168.10.1
192.168.20.0/24 dev eth3 proto kernel scope link src 192.168.20.1
222.22.222.8/29 dev eth1 proto kernel scope link src 222.22.222.10

The following policy routing rules:

root@router:/# ip rule show
0:      from all lookup local
32764:  from 192.168.20.0/24 lookup 222
32765:  from 192.168.10.0/24 lookup 111
32766:  from all lookup main
32767:  from all lookup default

In table 111:

root@router:/# ip route show table 111
default via 111.11.111.1 dev eth0

In table 222:

root@router:/# ip route show table 222
default via 222.22.222.9 dev eth1

In order to achieve your NAT goals, the router has the following nft ruleset:

table ip nat {
        chain router_masquerade {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 192.168.10.101 counter snat to 111.11.111.11
                ip saddr 192.168.10.102 counter snat to 111.11.111.12
                ip saddr 192.168.20.201 counter snat to 222.22.222.11
                ip saddr 192.168.20.202 counter snat to 222.22.222.12
                oifname "eth0" counter masquerade
                oifname "eth1" counter masquerade
        }
}

This applies the static NAT entries you list in your question, and applies regular masquerading to anything on lan1 or lan2 without an explicit entry.

With this configuration in place, if I run a tcpdump on remotehost, like this:

tcpdump -nn -i eth0

And then attempt to ping -c1 remotehost from node00, we see:

19:19:00.808202 IP 111.11.111.11 > 100.64.64.100: ICMP echo request, id 31, seq 1, length 64
19:19:00.808236 IP 100.64.64.100 > 111.11.111.11: ICMP echo reply, id 31, seq 1, length 64

The path from node00 to remotehost (a) has the expected source address and (b) is using the expected path. Similarly, if we try the same thing from node01, we see:

19:19:58.209656 IP 111.11.111.12 > 100.64.64.100: ICMP echo request, id 33, seq 1, length 64
19:19:58.209717 IP 100.64.64.100 > 111.11.111.12: ICMP echo reply, id 33, seq 1, length 64

Again, it's using the expected path, and we see that our externally visible address is 111.11.111.12, as expected from our NAT mappings.

If we attempt similar operations from nodes on lan2, we see from node10:

19:21:08.356388 IP 222.22.222.11 > 100.64.64.100: ICMP echo request, id 35, seq 1, length 64
19:21:08.356433 IP 100.64.64.100 > 222.22.222.11: ICMP echo reply, id 35, seq 1, length 64

And from node11:

19:21:30.824730 IP 222.22.222.12 > 100.64.64.100: ICMP echo request, id 38, seq 1, length 64
19:21:30.824799 IP 100.64.64.100 > 222.22.222.12: ICMP echo reply, id 38, seq 1, length 64

As far as I can tell, this behavior meets all of your goals.