fix: English UI rendered raw translation keys after the ngx-translate v18 upgrade

[hokiepokedad2]

Fixes #389

Fixes the v2.12.0 regression reported in Discord: every UI label renders its raw key (NAV.DASHBOARD, AUTH.SIGN_IN) — but only in English. Other locales are unaffected.

This is my regression from #377, and the "only English" shape is the clue that explains it.

Cause

The v18 migration renamed defaultLanguage → fallbackLang in provideTranslateService(). Those are not equivalent in timing:

• v17 defaultLanguage was inert — it recorded a preference and loaded nothing.
• v18 fallbackLang is loaded eagerly, from inside the TranslateService constructor.

So the config-level fallback resolves TranslateLoader while the injector is still constructing TranslateService:

NG0200: Circular dependency detected for `_TranslateService`

The HTTP loader catches this and downgrades it to a console warning (error loading translation for en), so nothing crashed and CI stayed green — English just never loaded. Every other locale is requested later via use(), after bootstrap, when the injector is complete. Hence a failure that looks language-specific but is really fallback-language-specific.

Fix

Drop fallbackLang from the provider config. I18nService.init() already calls setFallbackLang('en') after bootstrap, which is a safe point — no behaviour is lost.

Verification

Reproduced in the real deployment first. Loaded the dev instance in a browser and captured both symptom and cause:

heading "AUTH.SITE_TITLE_DEFAULT"
paragraph: AUTH.BRAND_DESC
button "AUTH.SIGN_IN_DISCORD"

[console] @ngx-translate/http-loader: error loading translation for en: NG0200

Then verified the fix in a browser, built and served locally:

heading "DM Alerts"
heading "Sign In"
button "Sign in with Discord"

NG0200 gone; the only remaining console errors are failed API calls with no backend running.

Regression tests drive the real appConfig providers rather than a hand-rolled copy, so re-adding fallbackLang to the provider config fails CI instead of shipping. Three cases: TranslateService constructs without a circular dependency, no translation is fetched before a language is requested (an eager fallback load would show up here), and English loads through the configured HTTP loader once requested.

I confirmed the tests actually catch it by re-introducing fallbackLang and watching them fail with the same NG0200: Circular dependency detected for _TranslateService.

875 frontend tests pass, lint and prettier clean.

Why unit tests missed it originally

The v18 migration's tests used provideTranslateService() with no loader, so translations resolved synchronously in-memory and the constructor-time load never happened. The bug needs the real provider wiring — config-level fallbackLang plus an async HTTP loader — which is exactly what the new tests now supply.