переделал токен

docs/DATABASE.md

@@ -48,6 +48,17 @@ erDiagram
         TIMESTAMP created_at
         TIMESTAMP updated_at
     }
+
+    auth_refresh_tokens {
+        BIGSERIAL id PK
+        BIGINT user_id FK
+        VARCHAR tenant
+        VARCHAR token_hash UK
+        TIMESTAMP issued_at
+        TIMESTAMP expires_at
+        TIMESTAMP revoked_at
+        VARCHAR rotated_to_token_hash
+    }
     
     education_forms {
         BIGSERIAL id PK
@@ -292,6 +303,7 @@ erDiagram
     student_groups ||--o{ schedule_rule_groups : "group_id"
     student_groups ||--o{ student_group_calendar_assignments : "group_id"
     users ||--o{ teacher_subjects : "user_id"
+    users ||--o{ auth_refresh_tokens : "user_id"
     users ||--o{ teacher_department_assignments : "teacher_id"
     departments ||--o{ teacher_department_assignments : "department_id"
     users ||--o{ teacher_lesson_types : "user_id"
@@ -379,6 +391,22 @@ erDiagram
 
 > **Триггер:** `update_users_updated_at` автоматически обновляет `updated_at` при любом `UPDATE`.
 
+#### `auth_refresh_tokens` — Refresh-сессии JWT
+| Колонка | Тип | Описание |
+|---------|-----|----------|
+| `id` | BIGSERIAL PK | ID refresh-сессии |
+| `user_id` | BIGINT FK → users (CASCADE) | Пользователь |
+| `tenant` | VARCHAR(100) | Тенант, для которого выдан refresh-токен |
+| `token_hash` | VARCHAR(64) UNIQUE | SHA-256 хэш refresh-токена |
+| `issued_at` | TIMESTAMP | Дата выдачи |
+| `expires_at` | TIMESTAMP | Дата истечения |
+| `revoked_at` | TIMESTAMP | Дата отзыва, `NULL` для активной сессии |
+| `rotated_to_token_hash` | VARCHAR(64) | Хэш следующего refresh-токена после ротации |
+| `user_agent` | VARCHAR(512) | User-Agent клиента |
+| `ip_address` | VARCHAR(64) | IP-адрес клиента |
+
+Сырой refresh-токен никогда не хранится в БД. При каждом `POST /api/auth/refresh` старый refresh-токен отзывается, а клиент получает новый refresh-cookie.
+
 ### Учебный процесс
 
 #### `education_forms` — Формы обучения
@@ -674,17 +702,17 @@ Seed создаёт `Базовая сетка` (`DEFAULT`) и `Субботня
 
 1. Все миграции находятся в `backend/src/main/resources/db/migration/`
 2. Формат имени: `V{номер}__{описание}.sql` (напр. `V1__init.sql`, `V2__add_departments.sql`)
-3. **ЗАПРЕЩЕНО** изменять уже закоммиченные файлы миграций — это сломает контрольные суммы Flyway
+3. **ЗАПРЕЩЕНО** изменять уже закоммиченные файлы миграций — это сломает контрольные суммы Flyway. Исключение допускается только по прямой просьбе пользователя и при полном сбросе tenant-БД.
 4. Flyway запускается **программно** при первом обращении к БД тенанта (`TenantConfigWatcher.initDatabaseForTenant()`)
 5. Настройка `baselineOnMigrate=true` — если в БД уже есть данные, Flyway начнёт с baseline
 
-> Текущая ветка календарного учебного графика является осознанным исключением: `V1__init.sql` переписан как новая базовая схема, а применение предполагает полный сброс БД без переноса старых данных.
+> Текущая JWT-правка является осознанным исключением по прямой просьбе пользователя: `V1__init.sql` обновлён как новая базовая схема, а применение предполагает полный сброс tenant-БД без переноса старых Flyway checksum.
 
 ### Текущие миграции
 
 | Файл | Описание |
 |------|----------|
-| `V1__init.sql` | Инициализация: справочники, роли, lifecycle-поля, история кафедр преподавателей, комментарии дисциплин, календарные учебные графики, динамическое расписание, версии/закрепления правил, точечные изменения расписания, тестовые правила, триггеры, комментарии |
+| `V1__init.sql` | Инициализация: справочники, роли, refresh-сессии JWT, lifecycle-поля, история кафедр преподавателей, комментарии дисциплин, календарные учебные графики, динамическое расписание, версии/закрепления правил, точечные изменения расписания, тестовые правила, триггеры, комментарии |
 
 ### Накатывание на существующих тенантов