fix(OFJAVA-017): CU-86akeeczr 2 review findings across 2 files

[flamingo]

Closes 2 review findings across 2 files.

Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.

#	Fix confidence	Finding	Location
1	🟡 70 medium	PackageSearchService.clientFor throws IllegalStateException for a configuration-level defect masked as runtime data issue	openframe-api-service-core/src/main/java/com/openframe/api/service/packagesearch/PackageSearchService.java:57
2	🔴 40 low — review closely	AppleTokenRevocationScheduler scans entire token repository unbounded and tenant-unscoped	openframe-authorization-service-core/src/main/java/com/openframe/authz/service/sso/apple/AppleTokenRevocationScheduler.java:38

What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.

---

Run: https://product-hub.flamingo.so/admin/code-review
Run id: 4f0d6344-55d4-49de-bc86-cac2510f432f

Merging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.

ClickUp task: CU-86akeeczr OpenFrame lib batch review findings sweep 2 (13 PRs)

[flamingo]

🦩 What this fix changed, finding by finding

2 finding(s) fixed in this draft — 2 explained inline on the diff; 1 low-confidence hunk(s) need close review before merging.

[flamingo]

🦩 🟠 PackageSearchService.clientFor throws IllegalStateException for a configuration-level defect masked as runtime data issue

In PackageSearchService's constructor, added a startup-time validation loop that iterates over all PackageManagerType enum values and throws IllegalStateException immediately if any type lacks a registered PackageManagerClient, so missing client wiring now fails fast at application boot rather than silently causing a per-request 500 via clientFor. The clientFor method itself is left unchanged (its check now becomes effectively unreachable defensive code, which is acceptable since it still documents/enforces the invariant).

🤖 Prompt for AI agents

In openframe-api-service-core/src/main/java/com/openframe/api/service/packagesearch/PackageSearchService.java around line 57, review and complete this code-review fix: PackageSearchService.clientFor throws IllegalStateException for a configuration-level defect masked as runtime data issue.
What the draft fix changed: In `PackageSearchService`'s constructor, added a startup-time validation loop that iterates over all `PackageManagerType` enum values and throws `IllegalStateException` immediately if any type lacks a registered `PackageManagerClient`, so missing client wiring now fails fast at application boot rather than silently causing a per-request 500 via `clientFor`. The `clientFor` method itself is left unchanged (its check now becomes effectively unreachable defensive code, which is acceptable since it still documents/enforces the invariant).
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟡 70 medium — react 👍/👎 to teach the reviewer

[flamingo]

🦩 🟠 AppleTokenRevocationScheduler scans entire token repository unbounded and tenant-unscoped

In revokeTokensOfDeletedUsers, replaced the unbounded tokenRepository.findAll() with a paged sweep using tokenRepository.findAll(Pageable) (Spring Data's PagingAndSortingRepository method) iterating pages of size 200 until exhausted, avoiding loading the entire token collection into memory at once. This addresses the unbounded memory-load concern but does NOT address tenant scoping — AppleUserTokenRepository was not shown/available to modify with a tenant-scoped query method, so a complete fix per OPENFRAM conventions (iterating per-tenant or filtering by tenant) still requires adding a tenant-aware repository method, which is outside what could be safely inferred/added without seeing that repository interface and the TenantScoped contract in this file's scope.

🤖 Prompt for AI agents

In openframe-authorization-service-core/src/main/java/com/openframe/authz/service/sso/apple/AppleTokenRevocationScheduler.java around line 38, review and complete this code-review fix: AppleTokenRevocationScheduler scans entire token repository unbounded and tenant-unscoped.
What the draft fix changed: In `revokeTokensOfDeletedUsers`, replaced the unbounded `tokenRepository.findAll()` with a paged sweep using `tokenRepository.findAll(Pageable)` (Spring Data's `PagingAndSortingRepository` method) iterating pages of size 200 until exhausted, avoiding loading the entire token collection into memory at once. This addresses the unbounded memory-load concern but does NOT address tenant scoping — `AppleUserTokenRepository` was not shown/available to modify with a tenant-scoped query method, so a complete fix per OPENFRAM conventions (iterating per-tenant or filtering by tenant) still requires adding a tenant-aware repository method, which is outside what could be safely inferred/added without seeing that repository interface and the TenantScoped contract in this file's scope.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

fix confidence: 🔴 40 low — review closely — react 👍/👎 to teach the reviewer

[michaelassraf]

Task linked: CU-86akeeczr OpenFrame lib batch review findings sweep 2 (12 PRs)