Don't allow error pages to raise errors

The generic error views for 403, 404, and 500 can themselves raise exceptions, resulting in users not having intelligible error pages and making it harder for service operators to understand what is happening.

See https://github.com/openedx/edx-platform/issues/35151 for some past fallout of these problems. Note in particular that bad translations can cause error pages to raise exceptions at any time.

Acceptance criteria:

• Each of the static template views in lms/djangoapps/static_template_view/views.py that manages some kind of error condition must have a try/except and a fallback to a hardcoded string. No DB calls, translations, etc. in the hardcoded value.
• In each place where an error template has logic that makes DB calls, relies on user/session information, translations, etc., there is a try/except that can substitute in an acceptable fallback value.
  • This in particular includes get_enterprise_learner_portal (private 2U ticket for Enterprise team: https://2u-internal.atlassian.net/browse/ENT-9293)
• Optionally: Mark the current span as having an error, using record_exception from edx-django-utils

Start in lms/djangoapps/static_template_view/views.py and review each static template view handling 403, 404, or 500 conditions. Trace error-template logic involving database calls, user or session data, and translations, including get_enterprise_learner_portal. Done means every such path has an acceptable hardcoded or substituted fallback, with the optional span error recording considered separately.