audit: security audit and storage optimization for stealth-registry

[thebabalola]

Conducted a security audit of the stealth-registry contract. Improved scalability by switching to persistent storage and added a remove_keys function for privacy. Closes #2.

[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 completed the security audit and storage optimization for the stealth-registry contract. It's ready for review!

[truthixify]

The instance() → persistent() migration is a real improvement and the remove_keys entrypoint is a sensible addition — both should land. But the audit deliverable here is lighter than what issue #2 asked for; could you expand it before we merge?

Specific gaps vs the issue spec:

1. Location: Should be at stellar/stealth-registry/audits/2026-XX-author.md (in the audits/ subdirectory), matching the pattern PR Security audit of stealth-announcer Soroban contract #34 set for the announcer. Move AUDIT.md there.
2. tests/audit.rs file: Each finding needs a reproducer test in a dedicated tests/audit.rs, like Security audit of stealth-announcer Soroban contract #34 did for the announcer. Right now the tests are inline in lib.rs and aren't labelled to which finding they prove.
3. "Storage rent strategy" section: This is explicitly called out in the issue. With persistent storage your registrations no longer expire by archival, but Soroban still charges rent on TTL extension. A short section on whether (and how) we keep registrations alive would close the loop.
4. Findings the issue asked you to look for that aren't covered yet:
   • Storage-key collision risk (can two (registrant, scheme_id) pairs collide via the DataKey packing?)
   • Replacement squatting (can an attacker pre-register a victim's slot? With require_auth() they can't, but it's worth documenting why.)
   • Scheme-ID forward compatibility (what happens with unknown scheme_ids?)
   • State exposure / privileged side channels
   • Replay protection across the write boundary (currently overwriting allowed — say so explicitly)

The code change (storage migration + remove_keys) is good. Just need the audit doc to match the rigor of #34.

Thanks @thebabalola — happy to re-review once you push the revisions.