docs: add splits vs manual multi-send explainer (Closes #144)

[olaleyeolajide81-sketch]

Summary

Closes #144. Adds an explainer doc comparing atomic splits to manual multi-send, and explains why atomic splits usually win. This is a documentation-only change — no contract, SDK, or app code is modified, so the Rust (cargo fmt / clippy / test), SDK, and App (npm run build) CI gates are unaffected.

What problem this solves

Issue #144 asks for a comparison that explains why atomic splits beat sending N separate transfers. When paying several parties, the naive path is to originate N independent transfers by hand. Tributary's split primitive instead stores the routing table on-chain and fans a single pay (or pay_many) out to every recipient atomically. The doc makes the trade-offs explicit so integrators reach for the right primitive.

Changes

• New doc docs/splits-vs-multisend.md covering:
  • What "manual multi-send" means (N independent transfers, each its own op/auth/settlement).
  • What a split does instead (pay / pay_many fan-out from one stored routing rule).
  • Why atomic splits win, with concrete reasoning:
    • All-or-nothing settlement — a split pays every recipient inside one transaction; partial failure (a bad address, broken trustline, lapsed allowance) cannot leave a half-paid state the way sequential manual transfers can.
    • One signature, one transaction — pay is a single authorization and network round-trip; pay_many extends that to several splits in one transaction.
    • Reusable and composable — the routing table lives on-chain and can be pushed through by anyone; splits can route to other splits, composing routing trees that would be error-prone to re-derive by hand every payment.
    • Exact, verifiable amounts — the contract computes each cut from fixed basis points and rounds dust to the last recipient (amount in = amount out), with preview_payout for exact per-recipient amounts before sending.
    • Inspectable routing — one readable split id vs a scattered set of transfers with no on-chain link.
  • Where manual multi-send still fits — one-off/ad-hoc payments, per-payment exact amounts that don't map to a stable basis-point table, and cases where you explicitly want each party settled independently even if another fails.
  • A comparison table (failure behavior, authorizations, reuse, composability, amount accuracy, routing visibility, best-for) and a bottom-line recommendation.
  • Two Mermaid diagrams (manual multi-send vs single pay) consistent with the style in docs/architecture.md.
• README.md — links the new doc from the Docs section, matching the existing doc-link format.

Why this is safe / reviewable

• One concern per PR (documentation only), per CONTRIBUTING.md.
• No contract behavior changed, so the no_std + typed-error requirements and contract tests are not implicated.
• No new code paths, so no new behavior tests are required.
• Only docs/ and README.md are touched.

Test plan

• Verified the new doc and the README link reference valid relative paths.
• Confirmed no source files (contracts/sdk/app) were modified.
• Maintainer to run cargo fmt --all, cargo clippy --all-targets -- -D warnings, cargo test, and npm run build in CI (unaffected by this change).

Checklist

• One concern per pull request
• Docs-only change, no behavior change requiring tests
• Contract code unchanged (stays no_std, typed errors preserved)
• Linked from README
• CI gates not impacted by this change
  closes Add a comparison: splits vs manual multi-send #144