annedi

OK, I think it has all come together now. I'll summarize so that a solution can be declared.
My website began to have sporadic image JPG upload failures. I couldn't completely correlate upload failures with image dimensions or file size, although upload failure did affect mostly large dimension JPGs. We had no problem with PNG uploads of any size.
We had been using ImageMagick all along. Lowering the ImageMagick quality setting did not fix the problem. Marc suggested switching to GD. That stopped the JPG upload failures. 
Thinking back, I realized that the upload failures began after the change to PHP 8.1.21. Randy suggested that the host might have missed setting some flag/option to ensure ImageMagick ran properly with PHP 8.1.21. So, as Marc suggested, I will ask my host to fix this PHP/ImageMagick incompatibility.
Thanks to SeNior-, Randy, Jim M and Marc for their useful suggestions and help. 😃

I fumbled and needed to edit the preceding post, but got locked out. So here it is again, complete this time.[hr]
SOLUTION (some of this is "notes to myself" for future reference")
After I created a Trouble Ticket, the Site5 tech discovered a Quality-of-Service error ("too many concurrent requests") for UVP in the server log of our shared server. Site5 included an excerpt from the log, but made no suggestions for dealing with the problem.
I ran a WhoIs on one of the IP addresses associated with the QoS error and learned that the requests originated from Singapore.
That led me to ask: were we being hit on or scraped by a bad crawler?
UVP has instructions in its robots.txt that instruct such bots and crawlers to go slowly. But obeying robots.txt is not mandatory. Bots misbehave all the time. If a bot is creating too many simultaneous requests for different pages and page elements, the server and the software cannot cope with the dense traffic.
Next I looked at our website statistics (cPanel>Metrics>Awstats), where it was clear that there was indeed some unusual Robot/Spider traffic beginning in May and dramatically increasing in the first half of July. In July we all saw constant ERROR 500 pages.
Then I looked in our UVP raw access logs (cPanel>Metrics>Raw Access) in order to attempt to find who was hitting on UVP excessively. The request string IP address in our raw access log matching the Singapore IP address belonged to Bytespider. (Google it to see that it has a bad bot reputation.)
Bytespider was blocked in .htaccess. UVP's web server log (cPanel>Metrics>Errors). Our web server log is now showing several current denials to Bytespider. Will Bytespider ever just give up trying to hit on us? Probably not.
We are no longer seeing any ERROR 500 pages. While I do not have rigorous proof that Bytespider was causing the problem, I'm going to assume for now that the problem has been fixed. I will continue to monitor more closely both our Unique Visitor traffic and our Robots/Spider traffic.
[hr]
FWIW, our Unique Visitor count never exceeds 8500. This is well within our shared server service limits. I was assured by Site5 that we do not need a larger service plan. We are really a small, specialized forum and typically do not exceed 50 viewers per day. We rarely have more than 20 viewers at any one time.
[hr]
Perhaps my write-up here will be helpful to someone else. I hope so. 
Can you delete the first, incomplete SOLUTION post? Thanks.

I figured it out!! 
Sorry to bother you!!
You can delete this topic.
I feel monumentally stoopid!! I created those "missing" PMs using a test login. OF COURSE, I wouldn't see those PMs under my normal login. 
We live but only sometimes learn. 😁🤪

I found it!!
If you create a new group,  you must go to
System > Site Features > Applications > System > Messages > Permissions
where you will see all the Groups listed. Find your new group and check the box Can Access Module.
Seems like it would be easier to have the Social Tab appear with the new Group creation and ask for that permission at the top.
This is solved. Thank you for giving suggestions!!
Andrea B.

I only had this "Upgrade Error" (involving a misspelling of the table name) just the one time during the Upgrade. Could  there be spelling error in your SQL upgrade script?
It's on me that not all the tables in my DB were of type InnoDB. For whatever reason in the past, that didn't seem to cause a problem. This time it did! So we can reasonably say that the solution here was to change all the table types to InnoDB.
Again thank you for the help!!
Andrea B.
P.S. I clicked the solution button to reference this post. It produced "solved by annedi". Please note that the solution was first provided above by Marc Stridgen. 😉