useResource$ race conditions when pagination key changes rapidly

Context

In Qwik v1.x, useResource$ deduplicates requests by key within a single render pass but does not expose an AbortSignal to the fetcher when the component unmounts or the key changes. When implementing cursor- or offset-based pagination, rapid key updates (for example, a user clicking "Next" multiple times or a debounced search input) leave in-flight requests for previous pages running to completion.

Observed failure mode

Those stale responses can arrive after the newer page's data, overwriting the correct state and causing UI flicker or corrupted lists. The framework RFCs discuss a usePaginatedResource$ helper and standard abort integration, but as of v1.5 no official primitive exists.

Constraints

• Backend already enforces LIMIT/OFFSET or cursor bounds; the issue is client-side request lifecycle.
• Manual AbortController wiring is possible but must be coordinated across SSR hydration and client navigation where the same loader may execute twice.
• Streaming SSR via streamResponse does not mitigate the race because the loader still returns a full page payload per key.

What patterns reliably cancel stale useResource$ fetchers on key change without breaking resumability? How should a custom pagination hook coordinate AbortController across server and client loader executions? Are there plans to surface a cancellation token in the useResource$ fetcher signature?