You can only do this for the devices that respect your DHCP-provided DNS config. Even if you redirect all port 53 traffic on your network to your pihole, a device can make its own (DoH or non-DoH) https connection and gets DNS responses via that, bypassing your pi-hole.
This was discussed extensively a few days ago on a thread about "72% of smart TVs and 46% of game consoles hardcode DNS settings":
Of course, that assumes IPv4, whereas with IPv6 and SLAAC I believe the only way is to firewall them out.
You essentially run a little proxy server on your pihole setup, and configure pihole to use it as your upstream dns resolver.
E.g., a proxy server running at 127.0.0.1:5053 which uses the Cloudflare ipv4/ipv6 DNS over HTTPS endpoints. This can also use other DoH endpoints as desired:
/usr/local/bin/cloudflared proxy-dns \
--port 5053 \
--upstream https://1.1.1.1/dns-query \
--upstream https://1.0.0.1/dns-query \
--upstream https://2606:4700:4700::1111/dns-query \
--upstream https://2606:4700:4700::1001/dns-queryhttps://tools.ietf.org/html/draft-dempsky-dnscurve-01
It’s being worked on again. The “client side” (from client to resolver) got all the attention in recent years. Even though it’s arguably less important than encrypting resolver to Auth traffic (as the resolver can often be close.).
Cynics say this is because there was money behind DoH which pushed it through standardisation, as the big providers are hungry for the data.
arguably the less important part of the equation
Basically sounds like you've already done the hardest parts. Your router is redirecting all DNS traffic to your pi-hole, this will prevent any normal unencrypted DNS traffic from leaving your local network. You pi-hole will be in turn making all the DNS requests. If you turn on DoH for the pi-hole all the DNS requests on your network will be encrypted.