fix(web): статус группы при группировке по дате + published-страница

- _fetch_candidates: статус группы = доминирующий (new>rejected>published),
  а не первого поста → при group_by=date группа «Ранее на этой неделе»
  больше не выглядит опубликованной (openchange fix-date-group-status)
- base.html: padding-top 1.5rem→4.5rem — заголовок не перекрывается fixed-top меню
- published.html: ID поста на карточках (#N · направление)
- AGENT.MD: бэкапы автоматические по крону, вручную не запускать

openspec/changes/fix-date-group-status/proposal.md

@@ -0,0 +1,51 @@
+## Why
+
+При переключении группировки списка кандидатов на «дата» (`/candidates?group_by=date`)
+статусные бейджи групп и правая панель вводят в заблуждение: часть групп
+(например, «Ранее на этой неделе», 52 поста) не получает бейджа статуса,
+а выбранный пост в правой панели может выглядеть как уже «опубликованный»
+(кнопка «Опубликовать» скрыта), хотя это — обычный кандидат.
+
+Причина: в `_fetch_candidates` статус группы вычисляется как
+`items[0]["status"]` — статус ПЕРВОГО (свежайшего) поста в группе.
+При группировке по дате первым в группе оказывается самый свежий пост,
+который может быть уже опубликованным или отклонённым, хотя вся остальная
+группа — новые кандидаты. Шаблон `candidates.html` рисует бейдж только для
+`new`/`rejected`, поэтому группа с первым published-постом выглядит «без
+статуса» (как опубликованная), а у selected-published поста скрыта кнопка
+«Опубликовать».
+
+Наблюдаемый симптом пользователя: «при переключении на сортировку по дате
+все кандидаты становятся отмеченными опубликовано и источник „Дед в АйТи“».
+
+## What Changes
+
+- В `web/app.py` (`_fetch_candidates`): статус группы считать не по первому
+  посту, а как ДОМИНИРУЮЩИЙ статус внутри группы:
+  - если в группе есть `new` → статус группы `new`;
+  - иначе если есть `rejected` → `rejected`;
+  - иначе если есть `published` → `published`;
+  - иначе — статус первого поста (запасной вариант).
+- Шаблон `candidates.html` остаётся без изменений (для `published` бейдж не
+  рисуется — это корректно: опубликованные не показываются в кандидатах как
+  активные). Исправление логики устраняет и ложный «published»-вид группы, и
+  неправильный вид правой панели для не-публикованных постов.
+- При `group_by=date` группа «Ранее на этой неделе» с 52 постами (51 new +
+  1 published) теперь получит бейдж «новые».
+
+## Why Not
+
+- Не менять сортировку постов внутри группы на статус: это сломает ожидание
+  «свежие сверху» для группировки по дате.
+- Не прятать published-посты из date-группировки полностью: пользователь
+  должен видеть, что именно опубликовано в этот период.
+- Минимальная правка в одном месте (`_fetch_candidates`) — не трогаем шаблон
+  и не меняем схему БД.
+
+## Impact
+
+- Файл: `web/app.py`, функция `_fetch_candidates`, блок вычисления
+  `"status"` группы.
+- Данные: без миграций БД.
+- Сервис: `vesti-web` (:8400) — требуется перезапуск.
+- Rollback: откатить правку в `_fetch_candidates` и перезапустить сервис.