fix(fonts): add unicode fallback for cyrillic

.github/instructions/docs.instructions.md

@@ -4,29 +4,19 @@ applyTo: '**/*.md'
 
 ## Documentation Guidelines
 
-- All documentation **MUST BE** in English
-- Use Markdown format
-- Keep `docs/ETC/COMMAND_LINE_PARAMETERS.md` updated with runtime-critical diagnostic flags and caveats (for example `-logToCon` behavior differences on Linux).
-- Don't add documentation files directly in the root `docs/` folder
-- The root folder `/` should only contain project-level files (README.md, LICENSE, etc.)
-- **Active Work**: Place in `docs/WORKDIR/` with appropriate subdirectory (phases, planning, reports, support, audit, lessons)
-- **Development Diary**: Update `docs/DEV_BLOG/YYYY-MM-DIARY.md` with daily entries
-  - Create new file each month (YYYY-MM-DIARY.md)
-  - Order entries newest to oldest (recent at top after Overview section)
-  - Keep entries informal and concise
-- **Reference & Historical**: Place in `docs/ETC/` (older reference materials, archived analysis)
-- **Phase Checklist Updates**: At the end of each session working on a phase, update the corresponding `docs/WORKDIR/phases/PHASEXX_*.md` file to mark completed tasks with `[x]`
-
-**Key Rule**: DEV_BLOG is for diary only. Active work goes to WORKDIR. Reference/historical materials go to ETC.
+- Docs in English, Markdown only.
+- Keep `docs/ETC/COMMAND_LINE_PARAMETERS.md` current for runtime-critical flags and caveats.
+- Never add docs in root `docs/`; use `docs/WORKDIR/` for active work, `docs/DEV_BLOG/` for diary, `docs/ETC/` for reference/history.
+- Update phase checklists in `docs/WORKDIR/phases/PHASEXX_*.md` at session end.
 
 ## Documentation Updates
 
-- **Dev diary** (`docs/DEV_BLOG/YYYY-MM-DIARY.md`): Informal session notes, newest first
-- **Session reports** (`docs/WORKDIR/reports/PHASEXX_SESSIONX_*.md`): Formal summary after significant progress
-- **Phase planning** (`docs/WORKDIR/phases/PHASEXX_*.md`): Update `[x]` checklist at session end
-- **Technical discoveries**: Place in `docs/WORKDIR/support/` (e.g., `CRITICAL_VFS_DISCOVERY.md`)
-- **Lessons learned** (`docs/WORKDIR/lessons/LESSONS_LEARNED.md`): Key takeaways from phases and work cycles
-- **Known Issues**: Track in [GitHub Issues](https://github.com/fbraz3/GeneralsX/issues/) — do NOT create new markdown issue files
+- Dev diary: `docs/DEV_BLOG/YYYY-MM-DIARY.md`.
+- Session reports: `docs/WORKDIR/reports/PHASEXX_SESSIONX_*.md`.
+- Phase planning: `docs/WORKDIR/phases/PHASEXX_*.md`.
+- Technical discoveries: `docs/WORKDIR/support/`.
+- Lessons learned: `docs/WORKDIR/lessons/LESSONS_LEARNED.md`.
+- Known issues live in GitHub Issues; no new markdown issue files.
 
 ## Documentation Organization
 
@@ -35,92 +25,54 @@ applyTo: '**/*.md'
 **Subdirectories**:
 
 #### `docs/WORKDIR/phases/` - Phase-Specific Plans
-**Purpose**: Detailed phase plans and checklists
-**Guideline**: use `PHASEXX_purpose.md` format for filenames - XX is phase number, purpose is brief description
-**Restriction**: Avoid using `weeks` for phase work segmentation, don't try to guess completion times in calendar weeks, just ignore this information entirely
-**Rationale**: Sprints provide a standardized Agile framework terminology, ensuring consistency with sprint-based development methodologies
+Plans and checklists. Use `PHASEXX_purpose.md` filenames. Ignore week estimates.
 
-**Naming Examples:**
+Examples:
 - PHASE01_INITIAL_RESEARCH.md
 - PHASE02_ENGINE_SELECTION.md
 - PHASE03_PROTOTYPING.md
-- etc.
 
 #### `docs/WORKDIR/planning/` - Planning & Strategic Documents
-**Purpose**: Planning documents, roadmaps, architectural decisions
-**Naming Convention**:
-- `PLAN-XXX_description.md` for individual plans
-- `ROADMAP.md` for overall project roadmap
-- Other strategic planning documents
+Planning docs, roadmaps, architecture decisions. Use `PLAN-XXX_description.md` or `ROADMAP.md`.
 
-**Examples:**
+Examples:
 - PLAN-010_VISUAL_LAYOUT.md
 - PLAN-013_PARTICLE_SYSTEM.md
 - ROADMAP.md
 
 #### `docs/WORKDIR/reports/` - Session Reports & Progress
-**Purpose**: Formal summaries after significant progress on phases
-**Naming Convention**: `PHASEXX_SESSIONX_description.md`
+Formal phase summaries. Use `PHASEXX_SESSIONX_description.md`.
 
-**Examples:**
+Examples:
 - PHASE01_SESSION1_INITIAL_RESEARCH_COMPLETE.md
 - PHASE02_SESSION2_ENGINE_SELECTION_COMPLETE.md
 
 #### `docs/WORKDIR/support/` - Findings & Support Documents
-**Purpose**: Technical discoveries, analysis, reference materials for active phases
-**Content Types**:
-- Technical analysis documents
-- Implementation findings
-- Code reference guides
-- Research supporting active work
-
-**Examples:**
+Technical discoveries, analysis, reference guides, and research support.
+
+Examples:
 - VFS_IMPLEMENTATION_FINDINGS.md
 - PARTICLE_SYSTEM_DEEP_ANALYSIS.md
 - TOOLTIP_CODE_REFERENCE.md
 
 #### `docs/WORKDIR/audit/` - Audit & Verification Files
-**Purpose**: Audit logs, verification checklists, compliance documents
-**Content Types**:
-- Structure audits
-- Implementation checklists
-- Gap analysis documents
-- Compliance verification
-
-**Examples:**
+Audit logs, verification checklists, compliance docs, gap analysis.
+
+Examples:
 - ROADMAP_AUDIT_DECEMBER_2025.md
 - GAP_ANALYSIS_FINDINGS.md
 
 #### `docs/WORKDIR/lessons/` - Lessons Learned
-**Purpose**: Key insights from phases and work cycles
-**Main File**: `LESSONS_LEARNED.md` - Central repository for all lessons
-**Content**: Phase-specific learnings, technical insights, process improvements
+Key insights, technical takeaways, process improvements. Main file: `LESSONS_LEARNED.md`.
 
 ### `docs/DEV_BLOG/` - Development Diary ONLY
-**Purpose**: Chronological development diary entries
-- YYYY-MM-DIARY.md - Monthly diary (ONE file per month)
-  - YYYY is the current year
-  - MM is the current month
-  - DIARY is a fixed literal
-  - Entries newest to oldest (most recent at top, after Overview)
-  - Informal, daily/session notes
-  - Short summaries of work done
-- `docs/DEV_BLOG/README.md` - Index of available diaries and overview of diary purpose with details on structure and usage
+Chronological diary entries only. One `YYYY-MM-DIARY.md` per month, newest first. Also `docs/DEV_BLOG/README.md`.
 
-**Only this goes here**: Diary entries and README
-
-**Not here**: Session reports, summaries, analysis, phase progress
+Not here: reports, analysis, phase progress.
 
 ## Issue Tracking — GitHub is the Source of Truth
 
-**CRITICAL POLICY**: All issues, bugs, feature requests, and enhancements MUST be tracked in **GitHub Issues** (`https://github.com/fbraz3/GeneralsX/issues/`), NOT in markdown documentation.
-
-### Why GitHub is Source of Truth
-- **Single source**: One place to track status, assign ownership, and manage priorities
-- **Versioning**: GitHub automatically tracks discussion history as features evolve
-- **Automation**: CI/CD, PR linking, and automation hooks depend on GitHub issues
-- **Collaboration**: Easier for team members to discover, comment, and contribute
-- **External visibility**: Users and contributors can search and report issues directly
+Track issues, bugs, features, and enhancements in GitHub Issues (`https://github.com/fbraz3/GeneralsX/issues/`), not markdown.
 
 ### Creating New Issues
 
@@ -135,21 +87,16 @@ gh issue create \
 ```
 
 **Labels** (always apply 1-2):
-- `enhancement` — New feature or improvement
-- `bug` — Something isn't working
-- `documentation` — Documentation improvements
-- `Linux`, `macOS` — Platform-specific
-- `Generals`, `Zero Hour` — Game variant
-- `Blocker` — Blocks other work
-- See `.github/instructions/docs.instructions.md` for complete label reference
+- `enhancement` — feature or improvement
+- `bug` — broken behavior
+- `documentation` — docs work
+- `Linux`, `macOS` — platform scope
+- `Generals`, `Zero Hour` — game variant
+- `Blocker` — blocks other work
 
 ### Markdown Documentation (Legacy)
 
-Older `.md` files in `docs/KNOWN_ISSUES/` are **DEPRECATED**.  
-- **Do NOT** create new markdown issue files
-- **Remove** files that duplicate active GitHub issues
-- **Archive** resolved issues in GitHub, then delete the `.md` file
-- **Migrate** any investigation findings to GitHub issue comments
+Older `docs/KNOWN_ISSUES/` files are deprecated. Do not create new markdown issue files; archive or delete duplicates after moving content to GitHub.
 
 ### Deleted/Resolved/Archived Issues
 
@@ -160,38 +107,10 @@ If an issue is closed/resolved in GitHub:
 
 ### Legacy `.md` Issues (Historical Reference)
 
-If you need to reference older markdown issues for historical context:
-- Keep in `docs/ETC/archive/` (not `docs/KNOWN_ISSUES/`)
-- Update the path and add a note that these are archived
-- Do not maintain these going forward
+Keep historical markdown issues in `docs/ETC/archive/` only. Do not maintain them going forward.
 
 ### `docs/BUILD/` - Platform Build Instructions
-**Purpose**: Platform-specific build and environment setup guides for active platforms (Linux, macOS, Windows, etc.)
-**Naming Convention**: One file per platform, all caps (e.g., `LINUX.md`, `MACOS.md`, `WINDOWS.md`)
-**Content**: Step-by-step build, deploy, and troubleshooting instructions for each supported platform. These are the canonical build docs referenced by contributors and CI.
-
-**Examples:**
-- LINUX.md — Linux build instructions
-- MACOS.md — macOS build instructions
-- WINDOWS.md — Windows build instructions (future)
-
-**Guidelines**:
-- All new build instructions must go here (not ETC)
-- Update cross-references in other docs to point to this directory
-- Keep instructions up to date with build scripts and CI
-
-**Not here**: General reference, historical analysis, or non-build docs
+Platform build/setup guides. One all-caps file per platform (`LINUX.md`, `MACOS.md`, `WINDOWS.md`). Keep them canonical and synced to build scripts/CI.
 
 ### `docs/ETC/` - Reference & Historical Materials
-**Purpose**: Older reference materials, archived analysis, and miscellaneous documentation
-- General reference materials
-- Archived technical documentation
-- Historical analysis documents
-- Miscellaneous project materials not fitting other categories
-
-**Guidelines**:
-- New active work should NOT go here
-- Use for long-term reference materials
-- Archive completed analysis here if still needed for reference
-
-**Not here**: Active phase work, current session reports, active planning, or build instructions
+Archived reference, analysis, and misc docs only. No active work, reports, planning, or build instructions.

.github/instructions/git-commit.instructions.md

@@ -4,7 +4,7 @@ applyTo: '**'
 
 # Git Commit Message Instructions
 
-Commit message standards based on [Conventional Commits](https://www.conventionalcommits.org/) specification, adapted for GeneralsX project needs.
+Use [Conventional Commits](https://www.conventionalcommits.org/) style, adapted for GeneralsX.
 
 ## Commit Message Format
 
@@ -18,7 +18,7 @@ Commit message standards based on [Conventional Commits](https://www.conventiona
 
 ### Type
 
-Must be one of:
+Use one of:
 
 - **feat**: A new feature
 - **fix**: A bug fix
@@ -37,32 +37,30 @@ Must be one of:
 
 ### Scope (Optional)
 
-- Name of affected code, file, directory, or logical component
-- Can span multiple scopes if needed (omit scope in that case)
-- Use lowercase with dashes (kebab-case)
-- Examples: `graphics`, `audio-openal`, `cmake-presets`, `dxvk-macos`
+- Affected code, file, directory, or component.
+- Can span multiple scopes; omit if needed.
+- Use lowercase kebab-case.
+- Examples: `graphics`, `audio-openal`, `cmake-presets`, `dxvk-macos`.
 
 ### Description/Subject
 
-- Succinct description of the change (readable without seeing the diff)
-- Use imperative, present tense: "add" not "added" or "adds"
-- Do NOT capitalize the first letter
-- Do NOT end with a period (.)
-- Keep under 50 characters when possible
+- Succinct, readable without diff.
+- Imperative present tense: "add", not "added" or "adds".
+- No leading capital, no trailing period.
+- Keep under 50 chars when possible.
 
 ### Body (Optional)
 
-- Additional context and explanation of **why** the change was made
-- Separate from subject with a blank line
-- Wrap at 72 characters
-- Include motivation, design decisions, or trade-offs
-- Reference related issues if applicable (e.g., `Fixes #123`)
+- Explain why, trade-offs, and design decisions.
+- Separate from subject with blank line.
+- Wrap at 72 chars.
+- Reference issues when useful.
 
 ### Footer (Optional)
 
-- Reference related issues or breaking changes
-- Format: `Fixes #<issue>`, `Closes #<issue>`, `Related-to #<issue>`
-- Breaking changes: `BREAKING CHANGE: <description>`
+- Reference issues or breaking changes.
+- Format: `Fixes #<issue>`, `Closes #<issue>`, `Related-to #<issue>`.
+- Breaking changes: `BREAKING CHANGE: <description>`.
 
 ## Examples
 
@@ -107,10 +105,10 @@ docs: update macOS build instructions for Vulkan SDK setup
 
 ## Commit Discipline
 
-- Commit logically related changes together (not by time/pressure)
-- One feature/fix per commit when possible
-- Keep commits small and reviewable
-- Write a commit message that explains **what** and **why**, not just **what** you changed
+- Group logically related changes.
+- One feature/fix per commit when possible.
+- Keep commits small and reviewable.
+- Explain both what and why.
 
 ## Quick Reference
 
@@ -128,12 +126,12 @@ docs: update macOS build instructions for Vulkan SDK setup
 
 ## Pull request guidelines
 
-- PR title should follow the same format as commit messages
-- the PR description should provide context and link to related issues
-- PR targets must be against main branch of `fbraz3/GeneralsX` repo, unless it's a user instruction to do otherwise (e.g., "Merge to `develop` branch" or "Merge to `feature/xyz` branch")
-- There is a subproject called `dxvk-macos` located under `references/fbraz3-dxvk` folder, which is a fork of the original DXVK project. Commits related to that subproject should be made in that repository and follow the same commit message standards.
-- `fbraz3-dxvk` subproject PRs should target the `generalsx-macos-v2.6` branch of `fbraz3/dxvk` repository, and follow the same commit message standards.
+- PR title follows same format as commit messages.
+- PR description gives context and links issues.
+- PRs target `main` in `fbraz3/GeneralsX` unless user says otherwise.
+- `dxvk-macos` work lives in `references/fbraz3-dxvk` and follows same standards.
+- `fbraz3-dxvk` PRs target `generalsx-macos-v2.6` in `fbraz3/dxvk`.
 
 ---
 
-**Note**: For GeneralsX code changes, also see `.github/copilot-instructions.md` for the code annotation standard (`// GeneralsX @keyword author DD/MM/YYYY Description`), which complements commit message discipline.
+**Note**: For GeneralsX code changes, also see `.github/copilot-instructions.md` for the code annotation standard (`// GeneralsX @keyword author DD/MM/YYYY Description`).