test(security): prevent token updates while refund balances remain

[Oyinkans0la12]

Closes #449

Summary

Add integration coverage to ensure accept_token_update cannot complete while contributors still have refundable balances tied to the previous token contract.

Problem

accept_token_update replaces the protocol's active token address. If escrowed refund funds remain in the previous token contract, later claim_refund calls may attempt to use the new token instead of the token actually holding the escrowed funds.

This could result in failed refund transfers or incorrect refund behavior for contributors with outstanding claims.

Solution

This PR introduces a regression integration test covering the partial-refund scenario and verifies that token updates are rejected whenever refund liabilities remain outstanding. If the existing validation is insufficient, the guard is tightened with the minimal required change to preserve refund safety.

Implementation Details

Integration Test

Added a regression scenario covering:

• campaign creation,
• contributor deposits,
• campaign cancellation,
• partial refund claims,
• remaining unclaimed refunds,
• proposed token update,
• attempted accept_token_update,
• verification that the update is rejected.

Validation

The test verifies that:

• token updates cannot strand refund balances,
• the active token address remains unchanged after rejection,
• existing refund claims continue using the original token,
• no partial state changes occur.

Regression Coverage

Additional assertions ensure:

• token updates still succeed when no refundable balances remain,
• existing behavior is preserved for valid upgrade scenarios.

Testing

Executed integration tests covering:

• partial refund with outstanding liabilities,
• successful token update after refunds are fully resolved (where applicable),
• rejection path validation,
• token state integrity after failed update attempts.

Behavioral Changes

None for valid workflows.

The protocol now explicitly prevents token updates from proceeding while contributor refund obligations remain unresolved, protecting escrowed funds from becoming inaccessible.

Checklist

• Added regression integration test for partial refund scenario.
• Verified token update rejection with outstanding refunds.
• Confirmed token address remains unchanged after rejection.
• Preserved valid token-update behavior.
• Added security regression coverage.
• Ready for review.

[drips-wave]

@Oyinkans0la12 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

[davidmaronio]

the two tests themselves are well built. test_token_swap_blocked_with_partial_refund_remaining_liabilities walks the exact dangerous window from the issue - cancel, partial refund, propose swap, advance past the delay, assert ValidationFailed, then drain the last refund and confirm the swap goes through - and the expired-unfunded variant covers the other path into refund liabilities. asserting the stored token is unchanged after the rejected accept and that contributor2 still gets paid in the original token is exactly the right level of paranoia.

what's blocking this:

1. the PR isn't scoped to the tests. the diff also carries README.md, docs/AUTHORIZATION.md, docs/THREAT_MODEL.md and a new docs/TRUST_MODEL.md - that's the content of your #691, which is itself a duplicate of #612. looks like this branch was stacked on the 691 branch. please rebase onto main so this PR contains only the src/tests/test_admin.rs changes.
2. required CI is failing. i suspect it's inherited from the stacked base rather than the tests themselves, but it needs to be green regardless - rebasing per point 1 will likely fix it. if not, gh run view the failing job and address what it reports.
3. heads up: #613 covers the same token-update-with-refund-balances scenario and is clean and likely to merge first. after it lands, please check whether your two cases add coverage beyond it (the expired-unfunded path may still be novel) and rebase to keep only what's new.

concrete ask: rebase onto current main, drop everything outside src/tests/test_admin.rs, and push so CI can go green.