perf: use hasMore instead of live count on merge suggestion lists

[skwowet]

Summary

List requests for merge suggestions were still slow on large project groups because every page load ran a live COUNT(*) in addition to the list query. This removes that bundled count: the API fetches one extra row to determine hasMore, and the UI paginates from that instead of res.count. Explicit countOnly calls are unchanged.

Changes

• Stop calling getTotalCount() on list responses in memberRepository and organizationRepository; return hasMore from a limit + 1 query instead of count
• Member and organization merge suggestions pages use hasMore for the load-more button instead of comparing total to loaded rows
• Data quality member/org merge suggestion lists use the same hasMore pattern for load more
• Member and organization merge suggestion dialogs use hasMore for next-page navigation and hasSuggestion for empty/actions state, replacing total-count-based prev/next and “X of Y” labels
• After merge or ignore in dialogs, refetch at the current offset and step back one page when that offset is empty

[github-actions]

⚠️ Jira Issue Key Missing

Your PR title doesn't contain a Jira issue key. Consider adding it for better traceability.

Example:

• feat: add user authentication (CM-123)
• feat: add user authentication (IN-123)

Projects:

• CM: Community Data Platform
• IN: Insights

Please add a Jira issue key to your PR title.

[Copilot]

Pull request overview

This PR improves merge-suggestion list performance by removing the bundled live COUNT(*) from standard list responses. Instead, the backend fetches limit + 1 rows and returns a boolean hasMore, and the frontend updates pagination/UI behaviors to rely on hasMore (while keeping explicit countOnly requests intact).

Changes:

• Backend memberRepository and organizationRepository now compute hasMore via limit + 1 queries and stop returning count on normal list responses.
• Member/org merge suggestion pages and data-quality lists use hasMore for “Load more” visibility.
• Member/org merge suggestion dialogs switch navigation/empty-state logic to hasMore + hasSuggestion, including refetch-after-action behavior.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
frontend/src/modules/organization/pages/organization-merge-suggestions-page.vue	Uses hasMore instead of total count to drive “Load more” pagination.
frontend/src/modules/organization/components/organization-merge-suggestions.vue	Dialog navigation uses hasMore/hasSuggestion; refetches and steps back when current offset is empty.
frontend/src/modules/member/pages/member-merge-suggestions-page.vue	Uses hasMore instead of total count to drive “Load more” pagination.
frontend/src/modules/member/components/member-merge-suggestions.vue	Dialog navigation uses hasMore/hasSuggestion; refetches and steps back when current offset is empty.
frontend/src/modules/data-quality/components/organization/data-quality-organization-merge-suggestions.vue	Data-quality org merge suggestions list uses hasMore for “Load more”.
frontend/src/modules/data-quality/components/member/data-quality-member-merge-suggestions.vue	Data-quality member merge suggestions list uses hasMore for “Load more”.
backend/src/database/repositories/organizationRepository.ts	Removes bundled count from list response; computes hasMore via limit + 1 and slices results.
backend/src/database/repositories/memberRepository.ts	Removes bundled count from list response; computes hasMore via limit + 1 and slices results.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[joanagmaia]

LGTM