Thank you Bernd and Erland for the detailed analyses. The solution I needed was for an internal test system, so my goal was to get it to work with SQL SErver "Force Encryption" on, but without a CA certificate, and to platform test the latest Microsoft OLEDB driver for SQL Server (v19). Because this is just for testing, I'm not worried about MITM attacks. Before I found a solution, I did install the self-signed certificate in the client's Trusted Root certificate store, and that worked fine, but I wanted to see if I could get it to work without installing the certificate, and the weird behavior of TrustServerCertificate=yes threw me.
The software I test is all on-prem behind firewalls, so some of our customers are not really worried that much about MITM attacks, or aren't willing to get a CA certificate, but they do want encryption to satisfy their corporate IT requirements. A security engineer would have an issue with my solution, I suppose.
The whole problem came about because our application had been hard-coding the MSOLEDBSQL provider for years and then all of us sudden, the application broke when I installed MSOLEDBSQL v19 and uninstalled v18. Since we don't know what OLEDB driver our customers will install, we enhanced our software to accept a connection string if the MSOLEDBSQL provider is not installed. My job was to figure out what connections string would work with a SQL Server that had Force Encryption on and a self-signed certificate. My problem is now solved, though I agree, it's not totally secure.
Thanks again for your comments.