v1.0.0 был тегнут на коммите, где Worker-уровневый фикс
(MessengerRequestIdListener) ещё не вошёл — служебные строки Messenger
теряли request_id. Патч-версия для реально рабочего состояния.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F5FspH2V3Tc4tvBapokCKV

Живая проверка первой версии показала: BroadcastEnvelopeHandler
выставлял ID только вокруг своего собственного тела метода, а
служебные строки самого Messenger ('Received message', 'was handled
successfully') логируются самим Worker'ом снаружи — до вызова шины и
после её возврата. В этом окне extra.request_id был пуст.

Contract\CarriesRequestId + MessengerRequestIdListener на
WorkerMessageReceivedEvent/Handled/Failed решают это на уровне воркера
целиком, а не хендлера — любое сообщение, реализующее интерфейс,
получает ID автоматически на всё время обработки, включая сервисные
логи. BroadcastEnvelopeHandler и EnrichPaymentReportJobHandler (Reports)
больше не занимаются этим сами.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F5FspH2V3Tc4tvBapokCKV

Один ID на весь путь запроса: генерируется на первом входящем HTTP-запросе
(или переиспользуется, если уже прислан), пробрасывается в исходящие
HTTP-вызовы через декоратор HttpClientInterface, автоматически попадает в
каждую лог-строку через Monolog-процессор. Через асинхронные границы
(Kafka broadcast, RabbitMQ-джобы) не пробрасывается сам — каждый такой
переход явно сохраняет/восстанавливает его в RequestIdStorage (см. README).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F5FspH2V3Tc4tvBapokCKV