test: cover buy/sell total supply updates and KeysSold event supply (#736, #738, #739)

[Yunusabdul38]

Description

Three Stellar Wave supply/event issues in this repo, one PR. Separate from #744 (issue #737), which is already open.

• Closes Add integration test for the KeySold event containing the correct seller address and supply after a sell #736 — KeysSold event carrying the seller and post-sell supply
• Closes Add unit tests for the sell function correctly updating the creator's total supply after each sale #738 — sell_key updating the creator's total supply
• Closes Add unit tests for the buy function correctly updating the creator's total supply after each purchase #739 — buy_key updating the creator's total supply

Contract change (#736)

KeysSoldEvent was the only trade event without a new_supply field — both KeysBoughtEvent and KeysBoughtBackEvent carry one. An indexer rebuilding supply from the trade stream therefore had nothing to read on a sell, so the field is added and populated from the post-sell profile supply.

That is the only production change in this PR; #738 and #739 are tests only.

Two places the issues and the contract disagree

Both are covered on whichever entrypoint actually enforces the rule, and called out in the test module docs:

"sell of 3 keys" / "buying 5 keys" — buy_key and sell_key each move exactly one key per call; there is no amount parameter. So these are 3 and 5 calls, and quantity in the event stays 1.

#738's insufficient_supply — sell_key cannot be asked for more than the supply, because it takes no amount; the balance guard fires first and returns InsufficientBalance, and selling past zero is refused rather than wrapping the u32. The contract's InsufficientSupply belongs to buyback, the sell-side path that does take an amount and rejects amount > supply. The tests assert both, so "cannot remove more keys than exist" is covered either way.

Test coverage

file	tests	covers
sell_event_seller_and_supply.rs	5	sells 3 of 10 and asserts the event's seller and new_supply (7) against both sell_key's return value and get_total_key_supply; a full sell-down to zero; the event not being attributed to an uninvolved holder; no event emitted on a sell rejected on balance or on slippage
buy_updates_total_supply.rs	8	1 key from supply 0 → 1; 5 buys on supply 10 → 15; sequential and interleaved buys across wallets; supply unchanged after buys rejected on underpayment, non-positive payment, the supply cap, and an unregistered creator
sell_updates_total_supply.rs	9	1 key from supply 5 → 4; full sell-down from 10 → 0; sells across two holders; selling past zero refused without underflow; buyback beyond supply rejected with InsufficientSupply; supply unchanged after sells rejected on balance, slippage, and an unregistered creator

Every supply case asserts the view against the value the call returned, after each individual call rather than only at the end.

Overlap with existing coverage

Worth being straight about: total_supply_per_creator.rs, key_supply.rs and supply_invariants.rs already cover parts of the happy paths in #738/#739. The genuinely uncovered gaps these add are the failed-buy supply invariance (supply_unchanged_after_failed_sell.rs covered only the sell side), the new_supply event field (previously only checkable via the return value), and the InsufficientSupply burn path.

Verification

step	result
cargo fmt --all -- --check	✅ clean
cargo clippy --workspace --all-targets -- -D warnings	✅ no warnings
cargo test --workspace	✅ 177 test binaries, 0 failures (22 new tests)