feat: add Stellar contract upgrade governance and migration plan

[thebabalola]

Added a comprehensive governance and migration plan for Stellar contracts. Outlined the upgrade mechanism, procedure, and future governance transitions. Closes #11.

[drips-wave]

@thebabalola Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[thebabalola]

Hi @maintainer, I've authored the Stellar contract upgrade governance and migration plan. Please take a look!

[truthixify]

The shape is right — admin + multisig + DAO transition is the right path — but a few things from the issue spec aren't in yet. Could you expand before we merge?

1. Filename — issue asked for stellar/GOVERNANCE.md. Rename UPGRADE.md → GOVERNANCE.md since this covers more than just upgrades.

2. Recommendation block at the top — "If we have to ship mainnet next week, what does the governance config look like?" — concrete answer. Number of signers, time-lock duration, specifically named guardians. The point of this doc is to make the decisions, not list options.

3. Per-contract upgradability decisions — for each of stealth-announcer, stealth-registry, stealth-sender, wraith-names, pick:

   • Frozen (no upgrade path)?
   • Multisig upgradable?
   • Timelock + multisig?
   • Eventually renounceable?

   The announcer and registry might want "Frozen" (recommended for trust-minimizing the most-watched contracts), while sender and names probably need upgrade capability. Argue each one.

4. Versioning — how do scheme_id bumps relate to contract redeploys? The event-topic redesign in docs: design Soroban event topic strategy for Stellar announcer #26 will be scheme_id=2; document the convention.

5. EVM comparison — short table mapping each Stellar decision to its EVM-side equivalent. Useful for ecosystem consistency.

6. Pause mechanism trade-off — argue both sides. Pause is a centralization vector; "no pause" is a reckless vector. Pick one and explain.

The implementation checklist at the bottom should become real follow-up issues once the doc is decided — file them with Stellar Wave label and link from here.

Thanks @thebabalola — this is the kind of doc that gets read by every future contributor, so the "make the decision" framing matters more than option-listing.