I can think of two possible explanations:
a. Your blocklists have changed.
You may have employed additional blocklists.
Your debug log suggests they all have been added on 2023-04-15 (though that may just be the case due to your current attempts to get Facebook operational).
But also, even without adding any lists, some of the existing blocklists may have been expanded with entries blocking facebook.
b. Your phones haven't been (always) subject to filtering at your previous destination
Your debug log suggests that your current RPi has only link-local IPv6 connectivity, as the resolution request via public IPv6 address is failing:
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] chogo16.com is :: on lo (::1)
[✓] chogo16.com is :: on eth0 (fe80::9620:ba6:b906:5a6c)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
If your previous ISP would have offered public IPv6 connectivity, and the router would have advertised its own IPv6 as DNS server (or your ISP's DNS servers), then there is a chance that your smartphones -with a tendency to prefer IPv6 over IPv4 - would have by-passsed your Pi-hole via IPv6. That would have allowed them to escape any facebook blocking, even if that would have already been in place before.
In both cases, your approach of whitelisting facebook domains should be able to address this.
Monitoring your Pi-hole's Query Log while a smartphone is attempting to connect to facebook should help you in identifying related blocked domains, and having a read of How do I determine what domain an ad is coming from? may also be helpful.
There is also a third possibilty, though I consider that unlikely:
Some ISPs offer filtering DNS requests at their end, e.g. as a parental control feature. I doubt that they'd filter facebook, but you'd probably want to verify whether such a service would be active for your connection nevertheless.