docs: updates repo size, GC, and 1.5 GiB expectations

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/GITEA_AUTO_UPDATE.md

@@ -394,6 +394,39 @@ git push origin v1.0.1
 
 ---
 
+## Размер репозитория `DndGamePlayerUpdates` (почему ~4 GiB и как держать меньше)
+
+### Почему место не возвращается само
+
+При **`DND_UPDATES_SQUASH_HISTORY=1`** и **`git push --force-with-lease`** на ветке **`updates`** в истории остаётся по сути **один актуальный коммит**, но на **диске сервера** Git до **сборки мусора** продолжает хранить **недостижимые** объекты: старые коммиты, прерванные push, временные ветки **`updates-upload-*`**, старые pack-файлы. Пока не выполнен **`git gc --prune`**, размер каталога **`.git`** на Gitea может быть **сильно больше**, чем «один релиз файлов» в веб-интерфейсе.
+
+### Сразу освободить место (один раз на сервере)
+
+На машине Gitea найдите **bare**-репозиторий (типичный путь: `…/gitea-repositories/<владелец>/dndgameplayerupdates.git`), от имени пользователя с правами на каталог:
+
+```bash
+cd /path/to/DndGamePlayerUpdates.git
+git gc --prune=now
+```
+
+При очень большом накоплении мусора иногда используют **`--aggressive`** (дольше и тяжелее для CPU); чаще достаточно команды **без** него. После GC размер на диске должен приблизиться к сумме **текущих** файлов в последнем коммите.
+
+В веб-интерфейсе Gitea смотрите раздел **администрирования** / **обслуживание** / **garbage collection** (названия зависят от версии): там может быть глобальный GC по всем репозиториям.
+
+### Чтобы после каждого релиза снова не раздувалось
+
+В **`app.ini`** Gitea включите **периодический GC репозиториев** (секция и ключи зависят от версии; ориентир — задача **`git_gc_repos`** в документации [config cheat sheet](https://docs.gitea.com/administration/config-cheat-sheet)), например раз в **24 ч** или чаще, если релизы частые.
+
+Уже включено в вашем пайплайне по смыслу: **squash** + **prune** старых имён установщиков — это уменьшает **набор файлов** в новом коммите; **физическое** освобождение на диске — задача **GC на сервере**.
+
+### Можно ли «всегда не больше 1,5 GiB»
+
+**Жёстко задать потолок Git не умеет.** Реальный минимум на диске ≈ размер **текущих** артефактов в ветке (два AppImage + NSIS + zip + blockmap + mac и т.д.) плюс служебные pack’и. Если один релиз по сумме бинарников уже **> 1,5 GiB**, репозиторий физически не уместится в лимит без **урезания артефактов** (например не выкладывать **`win.zip`**, если он не нужен updater’у) или без **выноса больших файлов из Git**.
+
+Надёжный способ держать репо **маленьким постоянно**: в **`DndGamePlayerUpdates`** хранить только **`latest*.yml`** (и при необходимости подписи), а **`.exe` / `.AppImage` / `.zip`** выкладывать в **Gitea Releases**, **объектное хранилище** или **статический хост**, а в yml подставлять **прямые URL** туда. Тогда потребуется доработка **CI** и, при смене хоста, **`build.publish.url`** / секреты — это отдельная схема доставки, не только `git gc`.
+
+---
+
 ## Если push отклонён: `(fetch first)` / `rejected`
 
 Пока job собирает артефакты, в **`updates`** мог успеть попасть **другой** коммит (второй релиз, ручная выкладка). Скрипт `sync-update-feed.mjs` перед push (в режиме **без** squash) делает **`git fetch` + `git merge origin/updates`** (и после клона — то же в начале), плюс shallow **глубина** (`DND_UPDATES_CLONE_DEPTH`: по умолчанию **40**, при **`DND_UPDATES_SQUASH_HISTORY=1`** в скрипте по умолчанию **8**). В режиме **squash** перед финальным push merge **не** выполняется — уже смерженное дерево отправляется через временную ветку и затем публикуется force-with-lease. Не запускайте **два релиза одного и того же репо одновременно** по двум тегам — возможны конфликты merge.