[Quality][Medium] Add explicit token-decimal normalization at integration boundaries

[Baskarayelu]

Objective

Define one internal unit convention and validate/convert external amounts exactly at the boundary.

Why this matters

Different tokens and off-chain callers may use different decimal conventions. Treating display units as contract units can misprice invoices or payouts.

This is a substantive production-quality improvement. It must change runtime behavior, security guarantees, correctness, reliability, or meaningful user functionality. It is not a documentation-only, formatting-only, or trivial dependency task.

Scope

Area: asset precision and integrations

Starting points: src/types.rs, src/payments.rs, src/fees.rs, docs/QLX_SETTLEMENT_ROUNDING.md

The contributor should verify the current implementation before changing it and keep the PR limited to this issue. Do not introduce unrelated refactors or weaken existing CI/security gates.

Acceptance criteria

• Every public amount parameter has a documented unit and conversion rule.
• Non-integral conversions are rejected or handled by an explicit deterministic rounding policy.
• The normalized amount is the only value used for authorization, limits, and transfers.
• Display-only formatting cannot influence settlement arithmetic.

Required validation

• Test supported precision, excess precision, zero, maximum, and conversion overflow.

• Test the same economic amount across all supported token precisions.

• Add a regression proving UI/display values are not used for transfers.

• The PR explains the failure mode, the chosen design, backward-compatibility impact, and rollback or migration considerations.

• The PR includes CI evidence and does not contain secrets, generated noise, unrelated cleanup, or disabled checks.

Contributor deliverables

• Open a focused feature branch and do not begin implementation until assigned.
• Reference this issue with Closes #<issue-number> or Fixes #<issue-number>.
• Check off every acceptance criterion in the PR with links to the relevant code and tests.
• Include a security/correctness note explaining why adversarial inputs cannot bypass the new guarantee.

Maintainer quality bar

The PR must be independently reviewable, preserve existing behavior outside this scope, exercise failure paths, and pass the repository's complete required CI/CD checks. Reward eligibility is not guaranteed by this issue or by merging.