Handle queued XRPL transactions before retrying

[RogerKSI]

Summary

• wait for an XRPL terQUEUED submission to reach a validated result using its original transaction hash
• prevent Falcon from fetching another account sequence and re-signing while that transaction is pending
• add regression coverage for txnNotFound followed by validated tesSUCCESS

Root Cause

Falcon treated every initial XRPL engine result other than tesSUCCESS as a broadcast failure. However, terQUEUED means the submitted transaction is pending and may still validate. Falcon immediately entered its normal retry loop, fetched a newer account sequence, and signed the same logical Oracle update again. When the original transaction subsequently validated, those later attempts produced sequence-related failures such as tefPAST_SEQ and repeated relay alerts.

Scope

• XRPL only
• transaction fee remains unchanged
• no behavior change for other chain providers

Validation

• go test -timeout=2m ./relayer/chains/xrpl -count=1
• go test -timeout=2m ./relayer/chains/... -count=1
• go vet ./relayer/chains/xrpl
• golangci-lint run --timeout=5m0s
• git diff --check

Limitation

The pending transaction is tracked in process until validation or service-context cancellation. Durable restart recovery and LastLedgerSequence expiry handling are intentionally outside this minimal fix.