some background first:
by default owrt is offering (DHCP and) DNS service for lan clients. DNS service covers for example knowledge about your clients (their name and ip address mapping), or which upstream DNS server to use in case owrt DNS cannot resolve a name (i.e. how to find public domain name ip addresses), or filter DNS.
now, let's focus on latter part, i.e. how to define which upstream to use.
the problem is that it is offer only, a client can decide not to use owrt's dns server (dnsmasq) which is set to use one particular upstream server (in one or other way, that's also a long story how many different way it can be set). simply setting the DNS server config on the client and it will go out straight to that upstream DNS server. so if you set DNS filtering on owrt it will be bypassed.
thus the idea which is called DNS hijacking: as DNS traffic is well known, if network admin redirects any attempt from clients on lan accessing the well-known dns port 53 in wan direction to the locally controlled/preferred dns server (=owrt dnsmasq), clients will not able to bypass the preferred dns filtering rules for example.
that was easy to do. but.
lots of clients nowadays (mobile phones, tv boxes, iot devices and web browsers ( ! ) too) using hardwired config pointing to whatever upstream DNS server not under your control/non-configurable/non-deactivable (if such word exists) way and with encrypted dns protocol such as DNS-over-HTTPS which is using port 443 it became impossible to use redirection technique. because port 443 for HTTPS is a legit traffic, you don't want to redirect normal HTTPS traffic to your dns server instead of the corresponding web server.
and here comes the second idea to mitigate it.
if these clients are using some known public DoH upstream server, because as above we cannot redirect or filter out based on port 443, let's reject connection to those server based on their ip addresses (as firewalls will not able to filter based on domain name) so they fallback to the offered dns server (which is our preferred server)!
and here we are: ip/nft set is a placeholder for ip addresses, as your nft ruleset shows doh/doh6 sets are created. but empty! something needs to fill it with ip addresses used by the public DoH servers.
and that when the 3rd idea came:
using owrt hotplug framework, let's hook plugins to the event when wan interface become active. that is done by the online hotplug you read in the wiki. it has two parts: one is creating the hook, the other is creating the plugins which will a) download the list of known DoH servers b) resolve their ip addresses and add to set.
this is where the wiki guide is not really up-to-date: till v21 ipset was used, the example codes are based on that. since v22 fw4 firewall (based on nftables) using it's own implementation called nft set. so the wiki example code will not work.
so in your case you need to solve two things:
- as you say your main router is not your gateway to internet and or not using wan interface. so trigger events when wan is up will not work for you. you need some other mechanism to download&resolve&add to set.
- and obviously you need to adapt the example code to use nft set syntax instead of ipset.
so you are almost there 
). Just know that you, my friend, are the only person that seem to know enough on this issue to help!
hopefully that don't give me more problems hehe.