Harden subscription batching and query pagination

[jdrains110-beep]

Summary

The subscription contract currently relies on caller discipline for batch and query sizing. That leaves two practical scaling problems in the current API surface:

1. process() accepts any limit, so a merchant can request an arbitrarily large batch in one transaction.
2. The only subscriber and merchant listing methods return the entire result set, which becomes hard to consume as subscription counts grow.

The current implementation also defers some approval-window arithmetic failures until later lifecycle calls even though the impossible configuration is known at service registration time.

Reproduction Points

• process() uses offset and limit directly with no contract-enforced ceiling.
• get_subscriber_subs() and get_merchant_subs() return unbounded Vec<Subscription> values.
• register_service() does not reject approve_periods / timestamp arithmetic that cannot fit the later approval calculations.

Proposed Fix

• Enforce a hard maximum batch size inside process().
• Add paginated query variants for subscriber and merchant subscription listings.
• Reject overflowing approval-window math during register_service() with TimestampOverflow.
• Add tests that cover the batch cap, paginated query behavior, and early overflow rejection.

Notes

I have a matching patch prepared and will open a PR that implements these changes.