docs: update render pipeline refactor spec base branch

The spec now reflects that the `refactor/render-pipeline` branch is cut from the current `main` (merge commit 88ac436) instead of the old `f9550d8` commit. Updated notes on cache behavior and clarified that no code changes are required at this stage. References updated for epic #34.

Refs #34

plans/2026-07-05-render-pipeline-refactor.md

@@ -5,9 +5,14 @@
 независимо подтвердил все line-refs и эмпирические утверждения спеки.
 v6: golden-корпус переведён с синтетики на записанные реальные сообщения
 (решение владельца, обоснование в этапе 0 и §8).
-База: ветка `refactor/render-pipeline` режется от **f9550d8**
-(`feat/kurigram-2.2.23`); все line-refs спеки действительны для этого коммита.
-Мёрж рефакторинга в main блокируется решением по kurigram-PR.
+База (обновлено 2026-07-05, после мёржа PR #21): ветка
+`refactor/render-pipeline` режется от **актуального `main`** (merge-коммит
+`88ac436`+), НЕ от голого f9550d8 — main теперь содержит kurigram-код
+(f9550d8) + review-fix `6388f2f` + саму эту спеку и корпус фикстур
+(коммиты docs). Все line-refs спеки по-прежнему действительны: `6388f2f` —
+чисто тестовый (только `tests/test_new_media_types.py`), source
+post_parser.py / rss_generator.py / api_server.py не сдвинулся ни на строку
+относительно f9550d8. Предусловие «kurigram в main» — ВЫПОЛНЕНО.
 Ишью: эпик [#34](https://gitea.vvzvlad.xyz/vvzvlad/pyrogram-bridge/issues/34),
 этапы 0–6 → [#27](https://gitea.vvzvlad.xyz/vvzvlad/pyrogram-bridge/issues/27),
 [#28](https://gitea.vvzvlad.xyz/vvzvlad/pyrogram-bridge/issues/28),
@@ -128,7 +133,8 @@ Golden-эталоны (§5, этап 0) обновляются только ко
 
 ## 4. Общие правила всех этапов
 
-- База: `refactor/render-pipeline` от f9550d8. Один этап = один коммит
+- База: `refactor/render-pipeline` от актуального main (88ac436+, содержит
+  f9550d8 + спеку + корпус). Один этап = один коммит
   (этап 5 — два: 5a/5b); после каждого — `pytest` полностью зелёный.
 - Правки существующих тестов допустимы в двух случаях: (а) тест закрепляет
   старое поведение из реестра §3 — правка с комментарием-ссылкой на номер
@@ -621,11 +627,13 @@ api_server зелёный.
 ## 7. Сознательно НЕ делаем (отложено)
 
 - Унификация глубины истории RSS (`limit*2`) vs HTML (`limit`).
-  Цена отложенности: кэш истории — ОДИН файл на канал, limit хранится внутри
-  и при несовпадении — miss (tg_cache.py:43–52, 106–109); канал с обоими
+  Симптом: кэш истории — ОДИН файл на канал, limit хранится внутри и при
+  несовпадении — miss (tg_cache.py:43–52, 106–109); канал с обоими
   потребителями живёт в вечном miss-цикле со взаимным вытеснением и
-  удвоенным RPC. Дешёвая альтернатива при взятии в работу: limit в имени
-  кэш-файла.
+  удвоенным RPC. НЕ отложено — чинится в отдельном эпике кешей (ишью #23,
+  Package B: префиксная выдача истории, `cached_limit >= limit` → hit).
+  Здесь ничего делать не нужно, но при мёрже учитывать пересечение (см.
+  комментарий к эпику #34).
 - `_reply_enrichment` в RSS-пути (RPC-нагрузка от частых опросов ридеров).
 - HTML-страница ошибки для `generate_channel_html` (сейчас RSS-XML).
 - Кэширование/демутация `_reply_enrichment` (мутирует кэшированные Message).