[Admin] Add token delist and whitelist revocation controls

[3m1n3nc3]

Description

Admin can whitelist tokens for giveaways, but cannot revoke support for a token after launch. Add token delisting so compromised or unwanted tokens can be blocked.

User Story

As a Protocol Admin,
I want to revoke token support after deployment,
so that Geev can react to token exploits, deprecations, or policy changes.

Requirements and Context

• Files / refs: contracts/geev-core/src/admin.rs, contracts/geev-core/src/types.rs, contracts/geev-core/src/test.rs
• Add a token-removal or token-disable function for DataKey::AllowedToken
• Ensure future giveaway creation rejects delisted tokens
• Define whether existing funded giveaways or requests using that token remain supported

Suggested Implementation

1. Add remove_token(token) or set_token_status(token, allowed)
2. Reuse admin auth checks
3. Persist the new token support state
4. Add tests for creation before and after delisting

Acceptance Criteria

• Admin can revoke token whitelist status
• Delisted tokens cannot be used for new giveaway creation
• The contract documents how previously funded records behave after delisting

Submission Guidelines

• Branch: feat/token-delist
• Depends on: None
• PR: feat(admin): add token delist and whitelist revocation controls

[shepherd-001]

Hello, I've reviewed the issue, and I am confident I can resolve it. Please assign the task to me.

[armandocodecr]

Hi, I'm Armando. This is a straightforward admin-controls addition on a Soroban contract, which I'm comfortable with.

My plan would be: in contracts/geev-core/src/admin.rs, add a set_token_status(token, allowed) (or remove_token(token)) function tied to DataKey::AllowedToken, reusing the existing admin auth checks rather than introducing a new pattern. I'll update the type definitions in types.rs if the token status needs to move from a plain whitelist entry to something with an enabled/disabled state, and make sure giveaway creation checks this status and rejects delisted tokens. For existing funded giveaways/requests on a token that gets delisted, I'll keep them honoring the token they were created with (delisting blocks new usage, not past commitments) and document that behavior clearly, unless the maintainers prefer otherwise. Tests in test.rs will cover: giveaway creation with an allowed token before delisting, rejection after delisting, and revoking/re-adding a token via the admin function. I'll work from feat/token-delist and follow the suggested PR title.

[Kaylahray]

Hi Maintainer, Please I can resolve this Please assign.

[grantfox-oss]

🦊 GrantFox — @Kaylahray has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #410)
2. Your PR will be reviewed by the geevapp maintainers

Good luck! Track your progress on GrantFox.