perf(syncer): batch concurrent Okta reads and reuse group scans

[somethingnew2-0]

What & why

The group membership and ownership sync passes issued one Okta list call per group, serially, so a sync run's wall-clock scaled linearly with the number of groups — the dominant cost of a run. This makes those per-group Okta reads concurrent.

Each pass now fetches a batch of groups' member/owner lists concurrently via asyncio.gather, then reconciles each result against the DB sequentially. The serial reconciliation is deliberate: the syncer shares a single AsyncSession, which must never be used concurrently, so only the network reads fan out. Batching in bounded groups (rather than prefetching every group at once) keeps peak memory to one batch of lists and keeps the number of concurrent Okta requests modest, so rate-limit pressure stays low (the SDK still retries any transient errors). A per-group fetch failure is captured and skipped rather than aborting the batch.

The batch size is set by the sync command's --group-batch-size flag (default 10, minimum 1).

Supporting changes in the sync command:

• Pool one Okta client (and its aiohttp connector) for the whole run so the concurrent fan-out reuses connections.
• Fetch the group-rule listing and the group listing once each, reused across the membership and ownership passes.

sync_groups keeps its own group-list fetch on purpose — in authoritative mode it creates/deletes groups in Okta, so the shared snapshot is taken after it runs to keep the later passes' behavior identical. sync_group_memberships / sync_group_ownerships take the shared groups and group-rule data as optional parameters (defaulting to fetching them) plus a required batch_size, so standalone and test callers are unaffected.

🤖 Generated with Claude Code