When both the Members and Open Review Requests columns are displayed on the

Groups datagrid (either on the All Groups page or the search results page), the

counts shown for each group are incorrectly inflated — often

by a factor equal to the other column's true count.
The root cause is a

Cartesian product in the SQL generated by Django's ORM.

GroupMemberCountColumn.augment_queryset_for_data() annotates the queryset

with Count('users'), and PendingCountColumn.augment_queryset_for_data()

annotates the same queryset with Count('review_requests', filter=...). When

both annotations are applied to the same queryset, Django generates a single

query with two M2M JOINs. These JOINs multiply each other — a group with 2

members and 3 open review requests produces 6 intermediate rows, causing both

COUNT() calls to return 6 instead of the correct values.
Both augment_queryset_for_data() methods now use distinct=True on their

Count() annotations. COUNT(DISTINCT ...) eliminates the duplicates

introduced by the other join, producing correct counts regardless of which

other M2M columns are active simultaneously. This is also the correct defensive

practice for any Count() across an M2M relationship.
https://docs.djangoproject.com/en/4.2/topics/db/aggregation/#combining-multiple-aggregations

Ran full test suite.
Added test_augment_queryset_for_data to both test files to verify each

  column produces correct counts on its own.
Added test_counts_with_both_columns_displayed to GroupListViewTests,

  which enables both the Members and Open Review Requests columns

  simultaneously, creates a group with 2 members and 3 open review requests,

  and asserts the counts are correct. Confirmed this test fails against the old

  code (returning 6 for both) and passes with the fix.
Visually verified on the All Groups page that enabling both the Members and

  Open Review Requests columns now shows correct counts and that the values on

  the Users and Review Request pages remained unchanged.