No client-side destination-address validation before hitting the SDK/network

[ndii-dev]

There is currently no send-flow UI to test this against directly, but the underlying gap already exists: nothing in src/services/stellar.ts validates a destination string's format before it would be handed to Operation.payment. A malformed G... address (wrong length, bad checksum, stray whitespace from a copy-paste) should fail fast and locally with a clear message — instead it will fail late, deep inside transaction building or Horizon submission, with a much less actionable error surfaced to the user.

Definition of done:

• A dedicated validateStellarAddress() covering both G... and (per the muxed-account issue) M... formats, used as the very first check on any destination input
• Clear, specific error messages per failure mode (wrong length vs bad checksum vs wrong prefix), not one generic "invalid address"
• Test matrix of valid/invalid address fixtures covering both formats

---

Before opening a PR for this issue, read CONTRIBUTING.md.

This is not a starter-issue. The Definition of done above is the full
acceptance criteria, not a subset to sample from — a PR that addresses part
of it is an unfinished issue, not a smaller one. Your PR must include, in
the PR description itself:

• Root cause / design-decision rationale in your own words — not a restatement of this issue
• Every Definition of done bullet above addressed explicitly, with a one-line note on how
• Evidence the code actually runs: pasted test/build output, a screen recording or before/after screenshots for UI changes, or real (non-mocked) logs for network/contract-facing work
• New or updated tests included and shown passing (paste the output)
• Any adjacent/related behavior this issue calls out re-verified, not assumed unaffected

PRs missing these will be sent back before review, not reviewed and rejected — please do this up front.

[Ayinkx1]

Hi i would like to work on this issue please assign to me
I can do it perfectly