feat(backend): introduce contract-aware transaction confirmation and retry state

[arisu6804]

Problem

Transactions can remain ambiguously pending after provider failures, causing repeated submissions or incorrect UI status.

Objective

Deliver a production-quality improvement to chain transaction orchestration and persistence that creates measurable value for correctness, security, reliability, performance, or maintainability.

Implementation scope

• Model pending, submitted, confirmed, failed, and unknown states with provider transaction identifiers.
• Use bounded, backoff-based confirmation retries and make worker restarts resume safely.
• Persist correlation data and distinguish replacement, reverted, and permanently failed transactions.

Acceptance criteria

• A restart or provider outage does not create duplicate submissions.
• Each terminal state is durable and externally consistent.
• Clients receive actionable status without exposing provider secrets.

Required validation

• State-machine tests, provider fault injection, restart/resume tests, and duplicate-submission integration tests.
• Existing tests and CI remain passing.
• Add regression coverage for the original failure mode.
• Do not weaken, delete, or skip unrelated tests to obtain a green build.

PR quality bar

• Keep the PR focused on this issue and explain design tradeoffs.
• Include test evidence, compatibility impact, and migration or rollout notes where relevant.
• Avoid typo-only, documentation-only, cosmetic-only, or unrelated refactor submissions.

Out of scope

• Broad rewrites not required by the acceptance criteria.
• Changes to unrelated services, contracts, or user flows.