fix(certificates): заменять сертификат уникальным поколением

deploy/TEST-ACME.md

@@ -29,3 +29,13 @@
 Для этих двух выдач и повторного назначения SSL необходимо согласие на конкретный сценарий. Разрешение250 относилось к уже завершённому тесту. До согласия выполняются только подготовка/чтение. Полная регрессия и Docker build для изменения лишь ручного acceptance helper не нужны; comparator проверяется отдельно. CA revocation и multi-instance здесь не принимаются.
 
 Нормативная справка для native полей/import: [MikroTik Certificates](https://help.mikrotik.com/docs/spaces/ROS/pages/2555969/Certificates). Документация не гарантирует успех повторного импорта в текущем приложении; именно это предстоит измерить.
+
+## Ротация поколений — подготовка258 (2026-10-15)
+
+Новый код проверяет неоднозначное исходное имя до CA order. Leaf/key импортируются под уникальным `<base>_new_<12hex>`. После проверки отпечатка/ключа оба SSL-сервиса переключаются на это поколение. Только после подтверждения назначений прежний объект переименовывается в `<base>_old_<12hex>`, новый получает исходное логическое имя, назначения и отпечаток проверяются повторно. Старый ключ не удаляется. API/DB requestId и certName остаются прежними; raw native IDs проверяются перед PATCH.
+
+Подтверждается сохранение старого native ID/fingerprint, освобождение логического имени и неизменность нового поколения. Неизвестный ACK или внешнее изменение не дают success; автоматического повторного PATCH/слепого rollback нет. При поздней ошибке нужно сверить фактические назначения и оба поколения. Это ещё не обещание отсутствия краткого TLS reload и не приёмка нескольких одновременно работающих issuers.
+
+Следующий реальный тест259: активировать подготовленный образ258, снять свежий baseline и выполнить согласованный first issue + scheduler renewal. Проверить ровно один leaf с логическим именем, один архив старого leaf с прежними ID/SHA-256/private-key и отсутствие незавершённых `_new_` объектов. Trusted TLS должен совпасть с новым leaf; canonical dates — с X509. Очистка должна учитывать собственные `_old_`/`_new_` имена с12hex, exact CN и записанные ID/fingerprints. Старый cleanup helper256, допускавший лишь exact logical/root имена, без адаптации не запускать. Удалять leaf поколения до собственных CA, затем проверить отсутствие и исходный export/files/services/settings. Чужие объекты не удалять.
+
+Образ258 подготовлен и проверен локальными service сценариями; до этого реального теста активный backend остаётся257. Повторное согласование того же уже разрешённого сценария не требуется. Продление не объявляется принятым по fixtures.