I solved the problem with the help of josephgodwinke, after 8 days of effort. Here’s the solution for anyone else who comes across this problem.
The short answer is to select Email > Email Debugger in the sidebar menu of CyberPanel. Then click the big red button that resets everything related to emails. Wait until it’s done, and then connect to your SMTP via your email client, such as Gmail or Thunderbird, and it should work.
Follow this guide for more: 9 - How to Debug and Reset Email Settings using CyberPanel Cloud
The longer answer is that my mail.domain’s SSL certificate’s validation period was stuck in the past. It was issued on Sep 11 and was only valid until Dec. 10. Yet no matter how many times I reissued the SSL, including deleting the existing SSL certificate via FTP and then issuing a new one, my Gmail continued to produce the same error mentioned at the start of this post. I failed to connect over a hundred times, and Gmail’s terrible error message was repeatedly useless.
I only discovered the cause of the problem by connecting to my SMTP via Thunderbird, and then trying to send an email. I could connect just fine, which was surprising, but then an error came up when I tried to send the email, so I clicked for more info to read the SSL’s validity dates. Validity: “Not Before Sun, 11 Sep 2022 04:14:37 GMT” and "Not After Sat, 10 Dec 2022 04:14:36 GMT. Gmail never provided this info. So if you’re stuck, try Thunderbird.
You could also do this manually. Afterward, Joseph mentioned to me that “you can find acme.sh and purge all the ecc keys and certificates for mail subdomain, and then reissue new ecc certificates the manual way.” Thankfully, CyberPanel’s Email Debugger does this as part of the reset process. But if you don’t have CyberPanel Cloud, then try the manual method.
If the CyberPanel developers read this post (@usmannasir), please set up a notification explaining that the new SSL certificate is still using the old expiration date, and that an email process needs to be reset. Then recommend that the user hit the reset button. Or instead of the nuclear option, send them to whatever process will reset that validity period. I feel like this should automatically be done as part of a new SSL certificate being issued for .mail subdomains. That way, other people won’t have to waste their time and energy (and stress!) to discover this.
Hopefully I won’t have to repeat this process in another 90 days. But if I do, it should be as simple as a click of that button.