feat: unify language handling across the application

- Updated the language configuration to use a single source of truth from `DEFAULT_LANGUAGE` for the bot, API, and Mini App, eliminating auto-detection from user settings.
- Refactored the `get_lang` function to always return `DEFAULT_LANGUAGE`, ensuring consistent language usage throughout the application.
- Modified the handling of language in various components, including API responses and UI elements, to reflect the new language management approach.
- Enhanced documentation and comments to clarify the changes in language handling.
- Added unit tests to verify the new language handling behavior and ensure coverage for the updated functionality.

.cursor/rules/frontend.mdc

@@ -35,7 +35,7 @@ export const state = {
   current: new Date(),          // currently displayed month
   lastDutiesForList: [],        // duties array for the duty list
   todayRefreshInterval: null,   // interval handle
-  lang: "ru"                    // 'ru' | 'en'
+  lang: "en"                    // 'ru' | 'en'
 };
 ```
 
@@ -58,7 +58,7 @@ t(lang, key, params?)  // → translated string
 ```
 
 - `lang` is `'ru'` or `'en'`, stored in `state.lang`.
-- `getLang()` resolves language from: Telegram `initData` user → `navigator.language` → `"ru"`.
+- `getLang()` reads **backend config** only: `window.__DT_LANG` (set by `/app/config.js` from `DEFAULT_LANGUAGE`). If missing or invalid, falls back to `"en"`. No Telegram or navigator language detection.
 - Params use named placeholders: `t(lang, "duty.until", { time: "14:00" })`.
 - Fallback chain: `MESSAGES[lang][key]` → `MESSAGES.en[key]` → raw key string.
 - All user-visible text must go through `t()` — never hardcode Russian strings in JS.