feat(#828): add configurable max buy quantity per transaction

[dedukpe]

Summary

Adds a per-creator limit on how many keys a single buy_keys transaction may purchase, preventing single-transaction supply grabs.

Closes #828

Changes

New Functions

Function	Description
set_max_buy_quantity(creator, max_qty)	Creator-only setter. Validates max_qty is 1..=10 000. Stores in persistent storage with TTL bump. Emits MaxBuyQuantityUpdatedEvent.
get_max_buy_quantity(creator)	Read-only view. Returns None when no limit is configured.
buy_keys(creator, buyer, payment, max_price, quantity, referrer)	Multi-key buy entry point. Computes total price across all keys on the bonding curve, validates payment, and processes each key individually with all per-key side effects (fees, dividends, TTL, events).

New Error Variants

Variant	Discriminant	Condition
QuantityExceedsLimit	54	quantity > max_buy_quantity
LimitTooHigh	55	max_qty > 10_000

New Event

MaxBuyQuantityUpdatedEvent ("mbq_upd"):

• Topics: (MAX_BUY_QUANTITY_UPDATED_EVENT_NAME, creator_id)
• Data: { creator_id, max_qty, ledger }

Key Design Decisions

• buy_key / buy_key_with_referrer unchanged — always purchase exactly 1 key. No breaking changes to existing callers (183+ call sites).
• buy_keys is the new multi-key entry point — accepts quantity: u32 parameter, enforces the per-transaction limit, and processes each key along the bonding curve individually.
• Each key in a batch is priced sequentially — supply increases with each key, so the price for key N is computed at supply + N.
• No limit = no check — when max_buy_quantity is not set (None), the check is skipped entirely with zero overhead.
• MAX_BUY_QUANTITY_LIMIT = 10_000 — hard ceiling for the setter to prevent unreasonable limits.

Pre-existing Fixes

The main branch had compilation issues from incomplete merges:

• Re-indented circuit breaker if block inside else branch (missing closing brace)
• Removed duplicate definitions (FEE_COLLECTED_EVENT_NAME, LOCKUP_BLOCKED_EVENT_NAME, credit_staking_rewards_pool, etc.)
• Added missing type stubs (AuctionConfig, StakingRewardsState, StakePosition, etc.)
• Added missing DataKey variants and ContractError variants

Acceptance Criteria

• Buy above max_qty panics with QuantityExceedsLimit
• Buy at or below max_qty succeeds normally
• max_qty above 10000 panics with LimitTooHigh
• Non-creator caller panics with Unauthorized
• max_buy_quantity_updated event emitted on change

Test Results

running 10 tests
test test_buy_keys_emits_event_on_set ... ok
test test_buy_keys_at_exact_limit ... ok
test test_buy_keys_exceeds_limit ... ok
test test_buy_keys_no_limit_set ... ok
test test_get_max_buy_quantity_returns_none_when_unset ... ok
test test_set_max_buy_quantity_at_limit ... ok
test test_buy_keys_zero_quantity_fails ... ok
test test_set_max_buy_quantity_by_creator ... ok
test test_buy_keys_within_limit ... ok
test test_set_max_buy_quantity_too_high ... ok
test result: ok. 10 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

[drips-wave]

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

[Chucks1093]

❌ CI Failed — verify (Contracts CI)

The verify check is failing on the max buy quantity feature.

Likely causes:

• max_buy_quantity storage key not reading with a TTL bump
• Missing error variant QuantityExceedsLimit in the error enum
• Unused variable warning treated as a compile error

Steps to fix:

1. Ensure the new error variant is added to the contract's error enum
2. Run cargo build to surface exact errors
3. Run cargo fmt --all and push

[Chucks1093]

Fix CI and merge conflict