User Story — отмена бронирования MeetRoom
Как организатор встречи, я хочу отменить ненужное бронирование,
чтобы переговорку могли использовать другие сотрудники.

Правила учебного примера
R1. Отменить активную бронь может только её организатор.
R2. Отмена разрешена, пока время сервера строго меньше времени начала.
    При равенстве или после начала — отказ. Время проверяется при отмене,
    а не только при открытии страницы.
R3. Отменённая бронь сохраняется в истории и больше не блокирует интервал.
R4. Повторная отмена своей отменённой брони подтверждает её статус,
    независимо от времени встречи. Другие брони не изменяются.
Организатор и время начала в этом упражнении не редактируются.

Критерии приёмки
AC1. Дано: своя активная бронь; других ограничений занятости нет.
     Когда: система принимает отмену до времени начала.
     Тогда: статус — cancelled; этот интервал можно забронировать снова.
AC2. Дано: бронь принадлежит другому сотруднику.
     Когда: пользователь запрашивает её отмену напрямую в API.
     Тогда: отказ; операция не изменяет бронь и не раскрывает её детали.
AC3. Дано: своя активная бронь.
     Когда: отмена обрабатывается ровно в момент начала или позже.
     Тогда: отказ; операция не изменяет статус брони.
AC4. Дано: своя бронь отменена; на её место уже создана другая бронь.
     Когда: пользователь повторяет отмену своей брони, даже после начала.
     Тогда: система подтверждает cancelled; новая бронь не изменяется.
AC5. Дано: ответ на отмену не получен.
     Когда: пользователь возвращается к карточке брони.
     Тогда: интерфейс запрашивает актуальный статус; при недоступности
     системы сообщает, что результат пока неизвестен, а не об успехе.

Use Case UC-CANCEL — отменить бронирование
Граница системы: MeetRoom, включая интерфейс и сервер.
Основной актор: сотрудник — организатор встречи.
Предусловия: сотрудник авторизован, выбрана существующая своя бронь;
            доступ к её деталям уже проверен.
Триггер: сотрудник выбирает действие «Отменить бронирование».
Основной сценарий:
1. Система запрашивает подтверждение отмены.
2. Сотрудник подтверждает отмену.
3. Система повторно проверяет права и актуальный статус брони.
4. Для активной брони система проверяет время и меняет статус на cancelled
   как единое согласованное действие. Бронь перестаёт блокировать интервал.
5. Система показывает отменённый статус.
Альтернативы:
2a. Сотрудник передумал — завершить без изменения брони.
3a. Доступ утрачен — отказ; эта операция ничего не изменяет.
3b. Своя бронь уже отменена — перейти к шагу 5 без изменения других броней.
4a. Время сервера не меньше времени начала — отказ без изменения статуса.
5a. Клиент не получил ответ — результат неизвестен; запросить статус.
    Если связи нет, сохранить сообщение о неизвестном результате.
Постусловие успеха: выбранная бронь имеет статус cancelled
                  и не блокирует интервал.
Гарантия при отказе проверки: эта операция не изменяет бронь.
Другие сотрудники могут независимо создавать брони на свободное время.

AC2 проверяет защиту API за пределами штатного UI-сценария UC-CANCEL.
Сбой связи не доказывает ни отмену, ни сохранение активного статуса.