Paginate listing of registered recipients

[sunnykid-02]

Closes #1210

---

Close: #1210

What was implemented
lib.rs
— 3 changes

1. New constant MAX_PAGE_SIZE = 50 Caps the entries returned per call, preventing runaway ledger reads.

2. Two new StorageKey variants

NameIndex(u32), // position → name (dense array 0..RecipientCount)
NamePosition(String) // name → position (reverse lookup for O(1) remove)
3. register_recipient — appends to the index After writing the RecipientRecord, it now also writes:

NameIndex(count) → name
NamePosition(name) → count
4. remove_recipient — O(1) swap-remove Instead of just decrementing the counter, it now:

Looks up the removed name's position via NamePosition.
If not already the tail, copies the tail name into that slot and updates its NamePosition.
Removes the vacated tail slot and both NamePosition entries.
5. New entrypoint list_recipients(start, limit) → Vec

No auth required — pure view.
limit capped to MAX_PAGE_SIZE; limit = 0 also uses the cap.
Returns empty vec when start >= count.
Reads NameIndex(start)..NameIndex(end) sequentially.
test.rs
— 7 new tests
Test What it covers
list_recipients_empty Returns empty vec on fresh registry
list_recipients_single_page All names appear within one page
list_recipients_pagination Multi-page walk covers all entries, no duplicates
list_recipients_page_size_capped limit=1000 still returns at most MAX_PAGE_SIZE
list_recipients_start_beyond_count_returns_empty Out-of-range start returns empty
list_recipients_removed_names_absent Removed names don't appear after swap-remove
list_recipients_no_auth_required Works with env.set_auths(&[])
list_recipients_zero_limit_uses_cap limit=0 falls back to MAX_PAGE_SIZE

[drips-wave]

@sunnykid-02 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