Fix: Amortise TTL refresh cost for paginated index views (#408)

[OluwapelumiElisha]

Description:

What does this PR do?
Addresses a simulation footprint / instruction budget DoS vulnerability in the factory contract's streams_by_sender and streams_by_recipient views. This is achieved by bounding the TTL-refresh loop (extend_page_ttls) to refresh a maximum of 3 pages per query, effectively reducing the read complexity from O(total pages) to O(limit).

Why is this change needed?
Prior to this change, every query to read_index invoked extend_page_ttls, which iterated over all 0..=(count-1)/PAGE_SIZE pages doing a persistent has() and extend_ttl() for each. For heavy senders with thousands of streams (e.g., 100 pages), this incurred up to 100 TTL refresh operations on every read, predictably exhausting the simulation instruction/footprint budget.

Changes proposed:
contracts/factory/src/index.rs: Refactored the extend_page_ttls function to perform a bounded amortised walk instead of a full loop.
The function now refreshes at most 3 pages (BATCH_LIMIT = 3) per call.
Uses env.ledger().sequence() % num_pages as a pseudo-random starting point, naturally distributing the TTL refresh cost over time without needing a persistent on-chain cursor.
Ensures queried pages in the window are still strictly refreshed on read (handled inherently by collect_page), while keeping older unread pages alive incrementally.

Related Issues
Closes #408

[drips-wave]

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