Стани замовлення в черзі доставки до 1С (orders_outbox)

POST /api/orders (режим replica) кладе рядок у queued; повтор того самого ключа стан не скидає
ORDERS_DISPATCH_MODE=inline (типово): той самий запит одразу пробує створити документ у 1С
runner: запит лише ставить у чергу; раннер (фаза доставки з ORDERS_DISPATCH=on) бере до 10 рядків за запуск через claim і звітує report
report приймається лише для рядка в creating, інакше 409
Крок outbox повного синку діє як inline; у режимі runner /api/sync/run його не планує

failed: claim бере рядок після паузи min(2^(attempts-1) хв, 30 хв): 1, 2, 4, 8, 16, далі 30 хв
claim спершу віддає рядки з меншим attempts; ліміту спроб немає
creating довше 10 хв - осиротілий: reclaim перед кожним claim і кроком outbox повертає його в queued
released: після збою зв'язку з 1С решту пачки раннер повертає без спроби і без +1: queued при attempts = 0, інакше failed
inline-спроба і крок outbox паузи не чекають; inline сам забирає осиротілий creating

queued, creating: клієнту «Прийнято, передаємо в облік»; менеджеру «У черзі порталу на передачу в 1С.» або «Саме зараз передається в 1С.»
failed: клієнту «Не вдалося передати в облік. Ми повторюємо спробу, менеджер бачить замовлення.»; менеджеру мітка «не передано в 1С», спроби й остання помилка
posted: клієнту «Передано в облік»; менеджеру «Документ у 1С створено, дані порталу ще не оновились.»
Помилку бачить лише менеджер. Тексти діють, доки документа немає в знімку 1С

rejected: кінцева відмова обліку на каналі service (наприклад PRICE_MISSING); не беруть ні claim, ні inline, ні reclaim
«Передати ще раз» (requeueRejected): rejected -> queued, спроби з нуля, ключ той самий; кнопка лише в менеджера
Клієнт бачить нейтральний текст без причини, менеджер - причину і кнопку
Канал рядка (ORDERS_CREATE_VIA: odata типово або service) закріплюється при постановці в чергу; шлях OData стану rejected не породжує