feat(payments): add validateSendXLMParams non-throwing helper (closes #87)

[Labi-Joy]

Closes #87.

Summary

Adds validateSendXLMParams(params), a pure non-throwing input-validation companion to sendXLM. Runs the same preflight checks sendXLM performs internally (secret key format, destination public key format, amount format + positivity + 7-decimal precision, memo byte length, self-payment detection) and returns a discriminated { ok: true } | { ok: false; errors: ValidationError[] } result. Callers can enumerate every field error at once to drive form UIs instead of catching thrown errors one at a time. Never touches the network.

Tests

npx vitest run tests/payments-validation.test.ts — 14 pass, 0 fail:

• happy path with and without memo
• invalid destination, invalid secret, invalid amount (non-numeric, zero, too-precise), memo too long (single-byte and multi-byte)
• self-payment when destination equals derived source public key
• multi-error collection in a single call
• self-payment check is skipped when the secret key is invalid (so we do not report a misleading SELF_PAYMENT alongside a real INVALID_SECRET_KEY)
• total-function behavior on runtime-junk input (never throws)
• stability check that codes match the documented union

Docs

• docs/getting-started.md gets a "Validating input before sending" block next to the sendXLM section.
• docs/api-reference.md gains a short function reference with the ValidationError type shape.

Notes for the reviewer

• Both sendXLM and validateSendXLMParams call the same underlying validateSecretKey, validatePublicKey, validateAmount, validateMemo utilities, so the "reuse the same validation logic" acceptance criterion is met without changing the existing throwing path. That keeps this PR small and low-risk for existing consumers.
• Consumers should branch on err.code, not on err.message. Codes are part of the SDK's public contract; messages are not.
• Pre-existing on main: tsc --noEmit still reports 8 errors in src/transactions/fixtures.ts from the recently-merged fixtures PR (TransactionDirection used as a value instead of a type, and id on TransactionSummary). Not touched by this PR, worth a follow-up.

[El-swaggerito]

This PR cannot be merged automatically because it has merge conflicts.

Please update the branch with the latest base branch and resolve the conflicts.

After the conflicts are resolved and checks pass, the automation can review it again.