merge: сведение ветки «Реклама Телеграм» с боевым main

Слияние feat/client-telegram-ads с main 8bdd58e8. Десять швов разобраны вручную:
денежный файл AdWalletService взят из main целиком — проверено поимённо, что все три
починки на месте: свой контекст клиента, оживление брони, таяние заморозки. В расписании
объединены оба набора заданий: телеграмные два и рекламные четыре. В боковом меню и в
мобильном «Ещё» сохранён пункт «Рекламный кошелёк», подписи поправлены — на реальные
экраны ведут ОБА канала. Словарь, пример настроек и журнал схемы объединены.

Сверх самого слияния:

- Журнал схемы: телеграмные записи v8.86-v8.95 перенумерованы в v9.18-v9.27, блок
  переставлен наверх, пометки «номер предварительный» сняты и заменены одной врезкой
  о перенумерации. Задвоенных номеров не осталось. Врезка шапки теперь называет и
  телеграмные таблицы: их DDL, как и рекламный, живёт только в дельта-миграциях.
- Новый сторож денег tests/Feature/ClientTg/TgMoneyUnderRealRoleTest.php: списание и
  возврат под боевой ролью crm_app_user. С контекстом клиента деньги двигаются, без
  контекста возврат падает громко. Обычные тесты ходят суперюзером и этот класс дыр
  увидеть не могут.
- Помощник rejectedCampaign переименован в tgRejectedCampaign: одноимённый помощник
  есть у рекламного модуля, помощники Pest глобальные, полный прогон падал фаталом.
  Каждая ветка по отдельности этого увидеть не могла.
- Два теста уведомлений считали ВСЮ таблицу целиком вместо строк своего пользователя:
  в одиночку зелёные, в полном прогоне красные. Счёт сужен до конкретного пользователя.
- Убраны две проверки отменённой сущности «своё имя отправителя» — сама сущность
  дропнута в v9.27 как СМС-фантазия, её адрес отдаёт 405.

Прогоны: телеграм 193/193, реклама 336/336 при 1029 проверках, вместе 532/532,
экраны 1704/1708, сборка фронта чисто, полный Unit+Feature 3923/3960. Шестнадцать
падений полного прогона совпадают построчно с прогоном ветки без телеграма — слияние
не добавило ни одного. Статанализ в свежем каталоге запустить не удалось: он требует
сгенерированного файла-подсказки, которого нет в репозитории, и без него молча падает
на обеих ветках.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

app/tests/Feature/ClientTg/InputLengthFixTest.php

@@ -12,8 +12,10 @@ use Illuminate\Support\Facades\Queue;
  * колонки проходило валидатор и падало на INSERT (22001), а глобальный хендлер
  * маскировал это под generic 422 «Не удалось сохранить» (как БАГ схемы в логах).
  * Теперь граница = размеру колонки → чистая ошибка ПОЛЯ (assertJsonValidationErrors),
- * а не замаскированная ошибка БД. Колонки: senders.name varchar(64),
- * campaigns.ad_link varchar(500), campaigns.ord_category varchar(200).
+ * а не замаскированная ошибка БД. Колонки: campaigns.ad_link varchar(500),
+ * campaigns.ord_category varchar(200). Проверки на senders.name убраны вместе с самой
+ * сущностью «своё имя отправителя» — она отменена в v9.27 как СМС-фантазия
+ * (таблица client_tg_senders и её endpoint дропнуты, запрос отдаёт 405).
  * Синтетические номера 7999… — реальных ПДн нет.
  */
 uses(RefreshDatabase::class);
@@ -36,18 +38,6 @@ function lenStorePayload(array $overrides = []): array
     ], $overrides);
 }
 
-it('имя отправителя длиннее 64 символов — ошибка поля name, не 500', function () {
-    $this->postJson('/api/telegram/sender', ['name' => str_repeat('и', 65)])
-        ->assertStatus(422)
-        ->assertJsonValidationErrors('name');
-});
-
-it('имя отправителя ровно 64 символа — не ложное срабатывание валидатора', function () {
-    // На 64 валидатор пропускает; дальше сервис (в песочнице деньги не трогает).
-    $this->postJson('/api/telegram/sender', ['name' => str_repeat('и', 64)])
-        ->assertStatus(201);
-});
-
 it('ad_link длиннее 500 символов — ошибка поля ad_link, не 500', function () {
     Queue::fake();