test: add upgrade migration tests for StealthRegistryContract

[ryzen-xp]

• Close [Wave 9] Add state migration tests across contract versions #189

Summary

Adds tests/upgrade_migration.rs to the stealth-registry crate. The existing upgrade auth tests prove who can (or cannot) trigger an upgrade — these new tests prove that storage state survives the v0→v1 migration and remains usable afterward.

---

What changed

• New file: stellar/stealth-registry/tests/upgrade_migration.rs with 9 tests covering:
  • Pre-upgrade snapshot records (injected directly into persistent storage) are readable via the v1 public API
  • Multiple users' snapshots are independently accessible
  • Records registered via the v1 API survive ledger advancement past TTL_THRESHOLD via auto-extend
  • Batch pre-upgrade records survive after first access
  • New writes land in persistent() with the canonical DataKey::MetaAddress shape and nothing leaks into instance() storage
  • Multi-scheme keys are stored independently and updates to one scheme don't affect others
  • Records written to the wrong storage tier (instance) are invisible to the v1 reader, documenting why rollback is not possible for a frozen contract
  • Wrong-length records are rejected at the API boundary with InvalidMetaAddressLength
  • Corrupted records injected directly are returned as-is, documenting the SDK's responsibility to validate on read
  • v1 event topics maintain the documented 3-topic schema so existing indexers continue to work

---

Why

The v0→v1 migration moved DataKey::MetaAddress from instance()/temporary() to persistent(). The previous test suite had no coverage of what happens to data across that boundary. Without these tests there is no regression harness if the storage tier or key shape changes again in future.

---

Testing

cargo test upgrade_migration -p stealth-registry

[drips-wave]

@ryzen-xp 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

[truthixify]

These are useful registry storage tests, but no upgrade is applied and there is no old-to-new implementation boundary. Please run real pre-upgrade contracts through each supported upgrade path, then verify old reads, new writes, and rollback behavior.

[truthixify]

The coverage moved to Sender and Names, but these tests still register only the current contract and write current DataKey values directly. No pre-upgrade WASM is installed and no upgrade path runs. Please test a real v0 to v1 upgrade before merge.

[truthixify]

Good progress on the WASM fixtures, but the tests still bypass the production upgrade path with env.as_contract. The names migration also copies storage through test-only access, not an executable contract migration. Please exercise the public timelock and multisig upgrade flow, add a real migration entry point or script, and run cargo fmt.