feat(contracts): add bounty_count() total-bounties view function

[Teemi2106]

Summary

Adds a bounty_count() view function to the contract that returns the total number of bounties ever created, and clarifies its semantic difference from the existing get_next_bounty_id().

Closes #754

Changes

• contracts/src/lib.rs

  • Added DataKey::TotalBountyCount, a dedicated persistent counter separate from DataKey::NextBountyId.
  • create_bounty now increments this counter by exactly one on every successful call, right after the bounty is written to storage.
  • Added bounty_count(env: Env) -> u64, a read-only view function that returns the counter's value (defaulting to 0 if no bounty has ever been created).
  • Added a doc comment on bounty_count() explaining what it does and how it differs from get_next_bounty_id().
  • Added a doc comment on get_next_bounty_id() pointing callers who want a total-bounty count toward bounty_count() instead, since get_next_bounty_id's value is really an implementation detail of ID allocation rather than a purpose-built counter.

• contracts/src/test.rs

  • Added test_bounty_count, which asserts:
    • bounty_count() is 0 before any bounty is created.
    • It becomes 1 after the first create_bounty call and 2 after the second.
    • It stays in sync with get_next_bounty_id() given the current sequential ID-assignment scheme (without depending on that being true for the API contract).

Design notes

The issue offered two implementation options: a dedicated counter, or deriving the count as next_id - 1. I went with a dedicated counter rather than deriving from get_next_bounty_id(), because:

• In the current implementation, DataKey::NextBountyId is only incremented at creation time and then used directly as the new bounty's ID — so it already equals the total count, not "the ID to be assigned next." Subtracting 1 from it (as literally suggested in the issue) would actually break the "returns 0 before any bounty is created" acceptance criterion (0 - 1 underflows for a u64).
• A separate counter keeps bounty_count() correct and self-contained regardless of any future changes to how bounty IDs are allocated (e.g. if IDs were ever made non-sequential or reused), rather than silently depending on that implementation detail.

Acceptance criteria

• bounty_count() returns 0 before any bounty is created
• bounty_count() increases by exactly one after each successful create_bounty call
• Doc comment clarifies the semantic difference from get_next_bounty_id()

Testing

No local Rust/Soroban toolchain was available in the environment I made these changes in, so I was not able to run cargo test / cargo build --target wasm32-unknown-unknown myself. Please run the test suite locally before merging — in particular:

cargo test --manifest-path contracts/Cargo.toml

I've reviewed the diff carefully for correctness, but automated verification is still needed.

[drips-wave]

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

[vercel]

@Teemi2106 is attempting to deploy a commit to the ritik4ever's projects Team on Vercel.

A member of the Team first needs to authorize it.