PrimeNG p-table lazy loading request ordering under rapid concurrent interactions

The goal is to configure p-table with lazy="true" so that rapid user interactions—sort, page, and filter changes—never leave stale rows visible after an earlier lazy-load response arrives late.

PrimeNG does not debounce, throttle, or cancel in-flight onLazyLoad operations, and concurrent responses can complete out of order. The application must therefore decide how to sequence or discard superseded LazyLoadEvent requests. Field availability such as multiSortMeta depends on the installed PrimeNG major version, so the version boundary must be confirmed before relying on combined sort metadata. PrimeNG also provides no automatic loading overlay; visibility is controlled only by [loading] or a custom pTemplate="loading".

Should the component track a request token and ignore responses from superseded LazyLoadEvent instances? Is a shared [loading] flag enough to block interaction while overlapping requests remain pending? Does the target PrimeNG major version expose multiSortMeta consistently?