Fix: Correcting Language Line fallback resolver

docs/localization.md

@@ -178,6 +178,24 @@ namespaced groups so nothing collides. `__()` resolves the translation for whate
 `App::getLocale()` currently is, which `LocaleMiddleware` already sets per-request (see
 "Behavior" above) — no extra wiring needed between the two systems.
 
+### Fallback locale follows the store's default language, not `config('app.fallback_locale')`
+
+`spatie/laravel-translation-loader`'s stock `LanguageLine::getTranslation()` falls back to
+`config('app.fallback_locale')` — a static `.env` value — when a key has no text for the current
+locale. That's a second, disconnected "default language" concept: an admin changing the default
+language via the Filament **Languages** resource has no effect on it, so an untranslated label
+could silently fall back to the wrong language.
+
+`Modules\Core\Localization\Models\LanguageLine` overrides `getTranslation()` to fall back to
+`LanguageCache::defaultLocale()` instead — the same `languages.default` flag `LocaleMiddleware`
+already treats as the single source of truth. It's swapped in via
+`config('translation-loader.model')` (the package's own documented extension point for
+"any model that extends `LanguageLine`"), set in `LocalizationServiceProvider::register()` so it
+wins regardless of provider boot order (Laravel's `mergeConfigFrom()` only fills in config keys
+not already set, so an explicit `register()`-time set always beats the package's own default).
+No consuming app configuration needed — this is automatic once `LocalizationServiceProvider` is
+registered.
+
 ### Seeding
 
 A starter set of common e-shop labels (`nav.*`, `cart.*`, `product.*`, `auth.*`, `search.*`,