bug(registry): reinstate does not verify the profile was actually revoked before reinstating it

[K1NGD4VID]

Summary

reinstate (lib.rs:467-489) unconditionally sets verified=true/revoked=false and emits address_reinstated for any registered profile, regardless of whether that profile was ever revoked:

pub fn reinstate(env: Env, address: Address) -> bool {
    ... admin auth ...
    let mut profile: Profile = ...
    profile.set_verified(true);
    profile.set_revoked(false);
    env.storage().persistent().set(&key, &profile);
    ...
    events::address_reinstated(&env, &address);
    ...
    true
}

There is no check equivalent to the one in revoke (which no-ops when !profile.verified()). Calling reinstate on a never-verified (Pending) profile silently performs the same state change as verify_profile(address, true), but emits the semantically wrong address_reinstated event instead of profile_verified, misleading any off-chain indexer that treats address_reinstated as "this address was previously revoked, now un-revoked."

Current Behavior

reinstate can be used as an undocumented alternate path to verify a Pending profile, emitting a misleading event. No test exercises this path — all existing reinstate tests first go through register -> verify -> revoke -> reinstate.

Expected Behavior

Either restrict reinstate to only operate on profiles where profile.revoked() is true (panicking or no-op-ing otherwise, similar to revoke's idempotency guard), or explicitly document that reinstate is a general-purpose "set verified" alias for verify_profile(address, true).

Acceptance Criteria

• Decide and implement the intended semantics for reinstate on a non-revoked profile
• Add a test covering reinstate called on a Pending (never-revoked) profile

Tech Stack

Rust, Soroban SDK, contracts/registry/src/lib.rs

[Stephan-Thomas]

@Stephan-Thomas has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

hi, i would like to work on this.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Stephan-Thomas to this issue.

[Lyonjohn]

@Lyonjohn has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’ve thoroughly reviewed the requirements and can work on fixing the issue while ensuring the implementation meets the acceptance criteria.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Lyonjohn to this issue.

[flexocode442]

@flexocode442 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi! This looks like something, let me work on this

ℹ️ Repo Maintainers: To accept this application, review their application or assign @flexocode442 to this issue.

[tzar-deek]

@tzar-deek has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello maintainer can I get on this issue for you real quick, I see that this issue aligns with one of the issues I fixed earlier, let me get on this for you real quick.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @tzar-deek to this issue.

[drips-wave]

Congratulations, @tzar-deek! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @tzar-deek: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊