Prevent duplicate or stale event data in shared TipContext refresh and pagination #284
Description
Summary
frontend/src/context/TipContext.jsx centralizes contract event fetching, but refreshEvents and loadMoreEvents can still append overlapping records without deduplication and without stronger stale-request protection for pagination.
Why this matters
The feed, activity views, and notifications depend on this shared cache. Duplicate or stale event records will produce inconsistent UI, inaccurate unread counts, and hard-to-debug user reports.
Proposed work
- Deduplicate events by deterministic identifiers such as tx id, event index, or tip id plus block height.
- Add stale-request guards for load-more requests similar to the existing refresh fetchId handling.
- Prevent refresh and pagination races from interleaving inconsistent arrays.
- Centralize event sorting so all consumers render the same stable order.
Acceptance criteria
- Repeated refreshes do not create duplicate records.
- Paginated loading does not append duplicate events when offsets overlap or requests resolve out of order.
- Shared event order is stable across feed, history, and notifications.
- Unit tests cover overlapping refresh and load-more scenarios.