fix(OMN-16026): bake seed-keycloak-clients.py into omninode-runtime image

[jonahgabriel]

Problem

The onex-dev Keycloak realm reconciler Job execs python scripts/seed-keycloak-clients.py with workingDir: /app against the digest-pinned omninode-runtime image.

The runtime stage of docker/Dockerfile.runtime has never COPYed scripts/. Every run of that Job died at exec time:

python: can't open file '/app/scripts/seed-keycloak-clients.py'

Observed live on onex-dev 2026-08-13 (Job seed-keycloak-clients, status Failed, 2 pods in Error).

The earlier attempt to close this was closed without merging, so the dependency it was supposed to satisfy never landed while the consuming manifest kept citing it as pending.

Why CI never caught it

The failure is exec-time, not build-time. A missing COPY produces a perfectly healthy image; nothing fails until a batch Job tries to run a path that isn't there. No existing gate exercised that path.

Change

1. COPY scripts/seed-keycloak-clients.py -> /app/scripts/seed-keycloak-clients.py in the runtime stage.
2. New deployment-seam test, tests/unit/scripts/test_seed_keycloak_clients_stdlib_only.py, pinning both properties this seam depends on:
   • the Dockerfile installs the script at the literal path the Job execs (the regression guard);
   • the script stays stdlib-only, because it is run as a plain file rather than via python -m — same import-cost reasoning as onex-container-healthcheck directly above it.

Copied as a plain file rather than exposed through the package for that documented import-cost reason.

Verification

$ uv run pytest tests/unit/scripts/test_seed_keycloak_clients_stdlib_only.py -q
3 passed

Live proof the fix is needed and sufficient: with this same canonical script mounted into a one-off Job on onex-dev (ConfigMap mount, correct admin URL), the reconcile succeeded and created the three declared-but-missing clients — realm omninode went from 10 clients to 13. That run is what confirmed the script itself is correct and the only blockers were packaging (this PR) and the admin URL (companion PR in omninode_infra).

Seams

Seam	Producer	Consumer	Matched
/app/scripts/seed-keycloak-clients.py	this Dockerfile COPY	omninode_infra seed Job command + workingDir	pinned by test_dockerfile_installs_the_script_at_the_invoked_path
stdlib-only import set	the script	plain-file invocation	pinned by test_module_imports_only_the_standard_library

Merge order

This must merge first, then CI builds+pushes omninode-runtime off the new dev HEAD, then the digest is bumped in lockstep in omninode_infra's two kustomization.yaml files. The companion omninode_infra PR corrects the stale ordering note to point here.

Evidence-Source: OCC#6478

Evidence-Ticket: OMN-16026

---

CI note (wave 2026-08-14T20:50Z): the prior wave's only classified red was Topic Enum Drift Check, which failed at 17:47:12Z with Failed to resolve action download info. Error: The HTTP request timed out after 00:01:40 -- an action-download egress timeout that occurred before any repository code executed. CI Summary failed downstream as the aggregator; the remaining jobs were cancelled, not failed. No job produced a content verdict. This body edit retriggers a clean CI wave. The head SHA is deliberately pinned and untouched.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 17 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: f9f8b0b0-b7f4-4d1e-b3e1-b481edfb86ac

📥 Commits

Reviewing files that changed from the base of the PR and between f15a491 and 5ecbb37.

📒 Files selected for processing (2)

• docker/Dockerfile.runtime
• tests/unit/scripts/test_seed_keycloak_clients_stdlib_only.py

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

❓ Hostile Reviewer — UNKNOWN

Blocking findings (critical): 0
Total findings: 0
Models succeeded: none

---

Gate semantics (pilot phase)

Verdict	Meaning	Blocks merge?
passed	No critical findings	No
blocked	CRITICAL findings found	Yes
degraded	All models unavailable (infra)	No (pilot)

Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8468/OMN-8524)