test: add exact-delta invariants for transfer_keys sender/recipient (…

[Topmatrixmor2014]

…#419)

Adds six integration tests in tests/key_transfer_sender_balance_decrement.rs that assert transfer_keys decrements the sender's key balance by EXACTLY the transferred amount and increments the recipient's balance by the same amount, while leaving total creator supply untouched. Each test computes an explicit before/after delta on KeyBalance and TotalKeySupply and asserts the delta equals the transfer amount, catching off-by-one regressions the existing absolute post-condition tests in transfer_keys.rs cannot detect.

Issue acceptance criteria (#419):

1. sender balance decremented by exactly the transfer amount
2. recipient balance incremented by exactly the transfer amount
3. total supply unchanged after transfer

Tests cover:

• single-key transfer (sender 5 -> 4, recipient 0 -> 1, supply 5)
• multi-key transfer (sender 10 -> 5, recipient 3 -> 8, supply 13)
• full-drain transfer (sender 4 -> 0, recipient +4, supply unchanged)
• three sequential calls (2 + 3 + 1) accumulating on the sender
• per-creator isolation (transfer under creator A leaves creator B intact)
• reverted call on insufficient balance (no state mutation)

Repair work required to land these tests:

• Remove stale duplicate transfer_keys in lib.rs that caused duplicate symbol errors under #[contractimpl]. The duplicate (env, from, to, creator, amount) was unreachable and inconsistent with the canonical (env, creator, from, to, amount) signature referenced by 22 existing tests and the KeysTransferredEvent topic name. Kept the canonical impl; deleted the stale one.

• Update tests/peer_to_peer_transfer_supply_regression.rs to call the canonical signature (was using the old arg order).

• Sync documentation: docs/key-transfer-authorization.md and docs/authorization-model.md had stale ZeroAddress/NotPositiveAmount error references and the old arg order wired into table rows and prose. Updated signature, code snippets, rationale paragraph, rejection bullet, and summary table to point at the canonical (creator, from, to, amount) signature and the dedicated ContractError::SelfTransfer / ContractError::ZeroTransferAmount variants.

Verify: cargo fmt --check / cargo clippy --workspace --all-targets -- -D warnings / cargo test --workspace all pass.

Summary

Testing

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace

Checklist

• Linked issue or backlog item
• Added or updated creator-keys unit/integration tests for every changed contract behavior, including failure paths for new or reachable ContractError variants
• Ran cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings, and cargo test --workspace, or explained exactly why a command was not run
• Reviewed persistent storage changes against docs/storage-key-invariants.md; any storage layout change includes a migration/backward-compatibility note
• Confirmed event names, topic order, payload field order, and field meanings remain compatible with docs/contract-event-conventions.md, or documented the breaking change and versioning plan
• Updated docs for any changed public contract interface, read-only method, event schema, storage behavior, fee logic, or deployment workflow
• Scope stays limited to one contract concern and does not include unrelated formatting, lockfile, generated artifact, or dependency changes

closes #419

[drips-wave]

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