Validate entropy source for `StellarSdk.Keypair.random()` on Expo/Hermes

[ndii-dev]

generateKeypair() in src/services/stellar.ts calls StellarSdk.Keypair.random() directly, which under the hood depends on a CSPRNG being correctly polyfilled in the Hermes/Expo runtime (expo-crypto or react-native-get-random-values typically need explicit setup for crypto.getRandomValues to be cryptographically sound rather than falling back to a weak Math.random-based shim some libraries silently use). expo-crypto is a listed dependency but is never imported anywhere in the codebase — confirm it's actually wired into whatever @stellar/stellar-sdk's random source resolves to at runtime on-device, not just present in package.json.

Definition of done:

• Runtime-verified (not just code-read) proof of which RNG implementation actually executes on both iOS and Android release builds
• Automated check (even a startup self-test) that fails loudly if the CSPRNG polyfill isn't correctly linked
• Documented remediation if the audit finds a weak fallback in use

---

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.