fix(scim): let remediate_keycloak_user_names run against production

[blarghmatey]

What are the relevant tickets?

Follow-up to #3836. Relates to mitodl/ol-django#538 (SCIM PATCH writing fullName: null, MITXONLINE-6PK).

Description (What does it do?)

remediate_keycloak_user_names couldn't complete a dry run against production, for two separate reasons.

• It loads every active SCIM-linked user into one dict before its first Keycloak request. Run with kubectl exec in a web pod, that exceeded the container's ~2.9GiB limit on 2026-09-18. The OOM kill restarted the pod's app container, not only the command. Given 8GiB in a dedicated pod, the load peaked around 6.8GiB.
• That load took about four minutes. The first Keycloak request then failed with InvalidTokenError, because the admin token had expired and KeycloakAdminClient couldn't renew it.

This changes three things:

• The command pairs Keycloak and mitxonline users one Keycloak page (100) at a time, using a scim_external_id__in query per page. The is_active filter is unchanged.
• The report lists up-to-date users as a count (up_to_date_count) instead of a row each. Nothing else in the repo reads the report.
• KeycloakAdminClient creates its OAuth2Session with grant_type="client_credentials". In authlib 1.7.2, OAuth2Client.ensure_active_token only re-fetches an expired token when that key is in the session metadata. Without it, a client-credentials token (which has no refresh token) just raises. The initial token request and ordinary requests are unchanged. b2b/provisioning.py, the other user of this client, now renews too instead of failing after one token lifetime.

would_patch and unpatchable still hold one row per affected user until the report is written. Their size depends on how many users need a fix. See the production numbers below.

How can this be tested?

docker compose run --rm web pytest b2b/keycloak_admin_api_test.py users/management/tests/remediate_keycloak_user_names_test.py: 51 passed. test_client_renews_expired_token fails with the grant_type line removed. That test calls ensure_active_token directly rather than sending a request through client.list.

Production dry run, with this branch's two modules loaded into a dedicated one-off pod (8GiB limit, not serving traffic), against 878,616 Keycloak users in the olapps realm:

• Memory stayed between 265 and 333MiB for the 35 minutes I let it run, against about 6.8GiB for the old code's user load.
• It kept paging well past the point where the old code died, about 4.5 minutes after fetching its token. That's about 2,680 GET /admin/realms/{realm}/users requests in 35 minutes, per Keycloak's http_server_requests_seconds_count.
• Keycloak's mean latency per page grew with the offset, from 0.51s to 0.86s over those 35 minutes, and the request rate fell from 1.6/s to 1.1/s. A full pass over 8,787 pages takes roughly three hours. Mean latency on Keycloak's non-admin endpoints stayed at 8-20ms, the same as before the run.
• I stopped that run because its pod's two-hour deadline would have cut it off before the end. A full run, in a pod with a five-hour deadline, finished in 2h51m: 0 patched, 400604 would-patch, 4873 unpatchable (no name data anywhere), 472847 already up to date.
• Peak memory for the full run was 1.27GiB, most of it the 400,604 would-patch rows and the 141MB JSON report built from them. Up-to-date rows no longer count toward that. It's still too much to share a web pod's ~2.9GiB limit with the app, so run it in a dedicated pod.

What the would-patch rows would change, computed in the pod from the report:

Keycloak vs mitxonline	Users
fullName missing, first/last not touched	361,103
fullName missing, first/last also differ from legal address	1,394
fullName present but different	19,540
fullName matches, first/last differ from legal address	18,567

361,103 of those only fill an empty fullName. The other 39,501 would overwrite a value Keycloak already has, which deserves a decision before running --apply on everyone.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ATK4bma3nXu3ZVza4hBrej

[github-actions]

OpenAPI Changes

Show/hide changes

## Changes for v0.yaml:
No changes detected

## Changes for v1.yaml:
No changes detected

## Changes for v2.yaml:
No changes detected

Unexpected changes? Ensure your branch is up-to-date with main (consider rebasing).