feat(messaging): support message status reconciliation

[barry01-hash]

Reconcile the relayer's tracked message status against the destination chain so a hung executor, a dropped completion callback, or a receipt that never finalised cannot strand a message in flight forever.

Closes #1164

What changed

• MessageQueue lifecycle API for reconciliation (backward compatible, purely additive):
  • markSubmitted(messageId, txHash) — records a broadcast transaction; the message stays in flight as submitted until completed, failed, or reconciled.
  • fail(messageId, error?) — force-fails an in-flight message with no further delivery attempt (used for on-chain reverts).
  • getMessageStatus() / getInflightSnapshot() — read-only tracked state for monitoring and the reconciler.
  • complete() now advances the message to confirmed on success, and a late duplicate completion (e.g. reconciler racing the executor) is recorded once so the real outcome is never overwritten.
  • Staleness is measured from the current delivery attempt (inflightAt, set at dequeue), so normal retries are never flagged stale.
• New MessageStatusReconciler — repairs drift in in-flight messages:
  • processing past staleAfterMs → re-queued for another attempt; failed once the retry budget is spent.
  • submitted + final receipt → confirmed; reverted receipt → failed immediately (deterministic); no receipt after staleAfterMs → re-queued for resubmission.
  • Fresh deliveries and chains without a provider are never touched. Provider faults leave messages in flight and count as errors.
  • Events: message-reconciled, stale-message-detected, reconcile-error, reconciler-degraded/reconciler-recovered, per-run reconciliation-summary; getStats() metrics.
• EvmExecutorStatusProvider — reference provider that reuses EvmExecutor.getTransactionStatus, so reconciliation shares the live confirmation policy rather than defining a second notion of finality. Other chain adapters (Soroban/Solana) build to the same MessageStatusProvider shape.
• Docs: new docs/MESSAGE_STATUS_RECONCILIATION.md (rules table, events, metrics, configuration, dependencies, troubleshooting) plus a cross-link from docs/CROSS_CHAIN_DUPLICATE_MESSAGE_DETECTION.md.

Verification evidence

• 295 tests passing (11 suites) after merging current upstream main into the branch: the 270 upstream tests (including PR test(messaging): reject malformed cross-chain messages at intake #1241's malformed-message validation) untouched plus our 26 reconciler, 11 queue-lifecycle, and 4 pipeline tests.
• message-status-reconciler.spec.ts covers normal/boundary/failure paths: fresh vs stale, retries exhausted, confirm/revert/not-found, provider throws/unknown/unavailable, degraded/recovered alerts, timers, run coalescing. 100% statement/function/line coverage (98% branches; one defensive formatting fallback).
• reconciliation-pipeline.spec.ts integrates queue → reconciler → executor → mocked RPC: executor-backed confirmation, lost-submission recovery (requeue then confirm), revert → permanent fail, and healthy deliveries untouched.
• tsc --noEmit clean; npm run build succeeds.
• Works alongside the merged validation (PR test(messaging): reject malformed cross-chain messages at intake #1241): intake validation and status reconciliation compose cleanly. The reconciler/pipeline fixtures now use a distinct source chain because the merged validator rejects sourceChainId === destinationChainId.

Notes for reviewers

• Pre-existing repo state (committed apps/relayer-service/node_modules is a broken install) required a local pnpm install --ignore-workspace to run tests; the tracked node_modules is committed untouched.
• The pre-existing jest "worker process failed to exit gracefully" warning reproduces on the baseline suites alone and is unrelated to this change.
• Labels ("Stellar Wave" etc.) require a maintainer; fork contributors cannot set them.

[drips-wave]

@barry01-hash Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits