eo locale is overloaded between tests and pseudolocale generation

[cfm]

Description

After #6406, we expect NEVER_LOCALE = "eo" to be, well, never available. It's how we test worst-case scenarios for the locale resolver, such as if an instance's default or even only configured locale loses support. This has been enforced in CI, including on freedomofpress/securedrop@develop, since May 2022.

After #6690, however, eo is available as the "pseudolocale" used to catch unmarked (untranslatable) source strings and test variable string widths. This has been available from Weblate on freedomofpress/securedrop-i18n@i18n since January 2023.

In effect, we've been operating in a partition between tooling and tests: the one violates the other's assumptions, but they only come into contact during the release/QA/localization cycle.

Steps to Reproduce

$ git checkout b0704e4c11a0c8f9de1db2fa64696230ad2d9ea4
$ TESTFILES=tests/test_i18n.py make test

Expected Behavior

Tests pass.

Actual Behavior

Failures:

tests/test_i18n.py::test_no_usable_fallback_locale FAILED                                        [ 25%]
tests/test_i18n.py::test_unusable_default_but_usable_fallback_locale FAILED                      [ 33%]

Comments

There are a few moving parts here:

1. The general solution to UnknownLocalError on for Occitan (oc) #6869 will let us address the confusion I raised in enable automatically-generated "pseudolocale" #6690 (comment) but never addressed: The values of NEVER_LOCALE and the pseudolocale should each (independently) be able to be whatever we want.
2. i18n branches and/or repository should run full CI workflow #6876

[cfm]

#6873 (comment):

The general solution to UnknownLocalError on for Occitan (oc) #6869 will let us address the confusion I raised in enable automatically-generated "pseudolocale" #6690 (comment) but never addressed: The values of NEVER_LOCALE and the pseudolocale should each (independently) be able to be whatever we want.

freedomofpress/securedrop-dev-docs#85 proves this to be wishful thinking. But the fix here turns out to be simple enough in #6919.