SOLUTION:
First, in the spirit of helping future users, since this applies to ALL 403 Forbidden errors in general, and not just this particular instance: it would be great if this solution could be posted somewhere as such, so someone else knows to seek help from their Website Provider instead of Moodle for, at least, an immediate workaround. As a newbie, it never occurred to me to look or think outside the Moodle box to solve a problem that was occurring within Moodle, especially since our Moodle was working perfectly for over a year using 3.10 and then 3.11 and only became unworkable with our upgrade to 4.04. Since I tried to post a more directly targeted error report regarding a LearnR Theme so it wouldn't get lost/buried, and my attempt was shut down as a "duplicate post", I assume a Moodle Moderator would need to do this.
For example, this solution also seems to have resolved our own multitude of instances with "I can't update questions", which I spent an entire week trying to resolve, as reported through my many troubleshooting updates posted here:
https://moodle.org/mod/forum/discuss.php?d=438024
No one replied there with any Web Application suggestions, as finally happened here. If it was a more widespread 403 Forbidden issue, it might have garnered more attention, but it wasn't and didn't, which makes it that much more important for anyone else dealing with a 403 Forbidden error to easily find a straightforward solution through a simple search in
MoodleDocs. As of now, if it wasn't for Leon and then Shiv suggesting here that the issue might be resolved through the Web Server, which led me to searching for and finding the first post about Forbidden errors (listed below), which then sent me to the 2nd post listed below about Mod_Security (which is quite old), my entire week of hell would only be stretching into two.
https://moodle.org/mod/forum/discuss.php?d=95086
Thus, it would be great if a specific post was provided that addresses 403 Forbidden errors and their solution to help others moving forward, which I assume a Moodle Moderator must do.
As for the solution itself: A workaround was indeed implemented through our Web Application's Mod_Security, though the error must still be rooted in Moodle 4, since it wasn't present in Moodle 3.10 or 3.11 (no?). When I told my VPS Provider that I was experiencing 403 Forbidden errors, he immediately suspected it was a Mod_Security issue and asked for a direct link to our Moodle website, including step-by-step instructions on how to recreate the error on his end. Luckily, the "Text Block" error occurred on a separately staged Clean install of Moodle 4.04, so there were no security, privacy, or IP related risks preventing me from giving him System Administrator access to this dev Website for him to recreate the error, which I could not have provided for our Main website.
In case we need to troubleshoot it moving forward, I learned that he used our Web Server's WHM/cPanel plugin within WHM called:
"ConfigServer ModSecurity Control"
...to check the apache logs and work on the website to 'force' the error, so he could see the actual ID that was triggering the mod_security. After that, he could whitelist the rule per
domain/subdomain name.
In this case, the Rule ID turned out to be "341256", in case this applies to others. This one rule exception also seems to have resolved our many instances of "I can't update questions".
While I still don't know exactly how to "whitelist the rule", which can be done using this plugin as well, I do know that the Apache log:
"/etc/apache2/logs/modsec_audit.log"
...can be checked with the above plugin, which lists the ID needed for the whitelist as well as more information on the errors, such as the example copied below. This way, we will at least be able recreate the issue ourselves and locate the ID required for whitelisting from the logs, then give the ID to our Host provider to Whitelist the ID for us (unless someone else can post how to do that here), without having to give them Teacher access to a Course, or System Administrator access to our Moodle.
Here are two Apache Error Log examples, in case they help with further troubleshooting of the 403 Forbidden within Moodle itself:
"detected XSS using libinjection. [file "/etc/apache2/conf.d/modsec/modsec_rules/12_asl_adv_xss_rules.conf"] [line "37"] [id "341256"] [rev "3"] [msg "Atomicorp.com WAF Rules: Possible Cross Site Scripting attack (detectXSS)"] [data "<p dir=\x22ltr\x22 style=\x22text-align: left;\x22>my title2 here</p>,ARGS:config_text[text]"] [severity "CRITICAL"]"
detected XSS using libinjection. [file "/etc/apache2/conf.d/modsec/modsec_rules/12_asl_adv_xss_rules.conf"] [line "37"] [id "341256"] [rev "3"] [msg "Atomicorp.com WAF Rules: Possible Cross Site Scripting attack (detectXSS)"] [data "<p style=\x22font-size:20px; color: rgb(0,75,200)\x22>welcome\x0a</p>\x0a<p style=\x22font-size:14px; color: rgb(0,75,200)\x22>we're currently using moodle, the wonderful open source learning management system, to manage our volunteer training for \x22 course\x22, \x22activity\x22 , and \x22quiz\x22 , elsewhere. still, volunteers like yourself..."] [severity "CRITICAL"]
Again, thanks to Leon and Shiv for sending me in the right direction as well as to those from the earlier posts; sincerely appreciated!!! And of course, much gratitude to all those that make Moodle possible, including everyone contributing to the forums; Moodle 4 looks great and we look forward to deploying it.
Jeff
As Ken puts it "In the Spirit of Sharing" 
