## ADDED Requirements

### Requirement: Claim раскладки коммитится до хардлинков и устойчив к сбою учёта

Раскладка — «claim-then-side-effect»: система SHALL сперва зафиксировать переход
задачи в `linking` (claim шага раскладки), и только затем создавать хардлинки.
Если запись claim перехода в `linking` провалилась, система НЕ SHALL создавать
хардлинки и SHALL прервать раскладку, оставив задачу в исходном состоянии
(`review`/`deferred` при ручном применении; `recognizing` при авто-раскладке) —
чтобы у шага сохранился владелец, а хардлинки не легли при незакоммиченном claim
(иначе финальный переход `linking → done` из фактического состояния был бы
отклонён графом, и задача застряла бы со stale-планом).

Если хардлинки уже созданы, но запись их учёта (`file_link`) провалилась
(транзиентная ошибка хранилища), задача НЕ SHALL оставаться в `linking`: система
SHALL перевести её в `review` с причиной. Повторное применение SHALL быть
идемпотентным — уже созданные хардлинки распознаются как существующие
(`StatusExists`), а их учёт дописывается.

#### Scenario: Провал claim не создаёт хардлинков

- **GIVEN** задача в `review` с готовым источником и валидным планом
- **WHEN** запись перехода в `linking` проваливается
- **THEN** хардлинки не создаются, учёт `file_link` не пишется
- **AND** задача остаётся в `review`, а команда отказывает с ошибкой

#### Scenario: Провал учёта уводит в review, не оставляя в linking

- **GIVEN** хардлинки по плану уже созданы на файловой системе
- **WHEN** запись строк `file_link` проваливается транзиентной ошибкой
- **THEN** задача переходит в `review` с причиной (код `persist`), а не остаётся
  в `linking`
- **AND** созданные хардлинки остаются на диске
- **AND** повторное «Применить» идемпотентно дописывает учёт и доводит до `done`