feat: token discovery and multi-token support

[ijeoma270]

The create form only lets you pick XLM or USDC. That's it. The stream contract accepts any Stellar token address — we're artificially limiting what users can stream.

Replace the hardcoded dropdown with an actual token selector. Users should be able to pick from a list of popular tokens (pre-populated) or paste any Stellar token contract address. When they paste a custom address, resolve the metadata (symbol, decimals, name) from the chain.

Build a TokenRegistry service that holds known tokens plus user-added ones (persisted in localStorage). The selector component should be searchable, show the user's balance for each token, and have a "recently used" section.

This needs to work everywhere — create stream form, payroll page, vesting form. Token symbols and icons should show up consistently in StreamCard, detail pages, analytics, everywhere.

Done when:

• Can paste any Stellar token contract address and it resolves
• Token metadata (symbol, decimals, name) fetched from chain
• Balance shown in the selector dropdown
• Popular tokens pre-populated, custom ones saved to localStorage
• Works in all forms across the app
• Invalid address shows a clear error, not a crash

[nighshift-labs]

I traced the public tip and prepared a bounded sample: deliverables/soroprotocol-token-registry-micro-delivery.md (issue-side summary below). The current app has duplicated native/USDC selectors, WalletContext exposes address/network but no chain reader, tokens are opaque strings in api.ts, and there is no Stellar client dependency.

The safe first slice is a network-scoped resolver + versioned local registry + shared selector/fallback states, with an injectable metadata/balance adapter. I would not invent token addresses or treat localStorage as authoritative.

Before a patch, could you confirm the canonical RPC/network names, whether metadata should come from SAC calls or the backend, the approved popular-token list/contract validation rule, and where the payroll route/API seam lives? The current public tree has create-stream and vesting forms but no payroll page. The inspected tip installs and builds cleanly, so this can stay isolated from unrelated build work.