Filter-based bulk user delete silently capped to the first page (20 users) #7066

Summary

A filter-based bulk user delete (DELETE /orchestrator/user/bulk with a listingRequest and no explicit ids, e.g. {"listingRequest":{"searchKey":"abc"}}) only resolves and deletes the first 20 matching users. All remaining matching users are silently left in place.

This is the opposite of the original over-deletion incident fixed in #7021.

Root cause

getUserIdsHonoringFilters in pkg/auth/user/UserService.go (called from BulkDeleteUsers):

1. Calls impl.userCommonService.SetDefaultValuesIfNotPresent(request, false) (pkg/auth/user/UserCommonService.go:815-826), which sets Size = bean.DefaultSize (20) when unset.
2. Builds the query via helper.GetQueryForUserListingWithFilters (pkg/auth/user/repository/helper/UserRepositoryQueryBuilder.go:54-57), which appends limit ? offset ? unless ShowAll (or CountCheck) is set.
3. Nothing sets ShowAll on this path, so the query is paginated and only one listing page of user ids is resolved for deletion.

Expected behaviour

A filter-based bulk delete applies to every user matching the filter, consistent with what the listing filter implies, not to a single page of results.

Notes

The same bug was already fixed in devtron-enterprise via devtron-labs/devtron-enterprise#3407 by setting request.ShowAll = true in getUserIdsHonoringFilters after the normalization calls.