chore(OMN-16041): backmerge main lineage into dev alongside the v0.38.5 promotion

[jonahgabriel]

OMN-16041 — backmerge main lineage into dev

This is the dev-side half of the promotion that landed on main as #2744. It exists so the two branches stop re-conflicting on every promotion, and so dev does not silently regress the fixes that live only on main.

---

Conflict resolution — 2026-08-18

The branch had gone stale (opened 08-14, main promoted 08-15, dev moved 13 commits since). Current dev was merged in and the conflicts resolved by reading both sides' history per path rather than taking a side wholesale.

Only two files actually conflicted, and both were the same line:

File	main lineage	dev	Decision	Why
pyproject.toml	0.38.5	0.38.7	dev	main is already at 0.38.6. dev's 0.38.7 is above it, so the release-identity gate is satisfied without any bump here; taking the branch's stale 0.38.5 would have pushed dev below the released version.
uv.lock	0.38.5	0.38.7	dev	Same line, same reasoning — the lock's own package entry must track pyproject.toml.

Everything else merged without textual conflict. Each auto-merged path was still checked by hand against both branches, because "no conflict marker" is not the same as "correct":

File	Authoritative side	Reasoning
.github/workflows/deploy-gate.yml .github/required-checks.yaml	main	These pin the shared deploy-gate workflow by commit. main pins one commit from 2026-07-25 in both files. dev pins two different commits — 2026-07-20 in the workflow and 2026-07-19 in the manifest — so dev was both older and internally inconsistent with itself. Taking main moves to the newest pin and makes the two files agree again.
.github/workflows/env-parity.yml	main	main widened the sibling-checkout token to try the org-wide token before falling back, because the default token cannot read the private sibling repo. dev never received it and still has the narrower two-option form. Nothing on the dev side competes.
.github/workflows/artifact-reconciliation-webhook.yml	main	main-only CI change from the previous bridge; dev has not touched this file since the branches diverged.
scripts/validate_handler_contracts.py	main	The strongest case in the set. dev still carries the original version, which validates a hardcoded list of seven handlers at nodes/handlers/<name>/contract.yaml — a directory that no longer exists in either branch. main replaced that with a glob over the live descriptor location. Verified by running it on the merged tree: 5/5 contracts validated, 0 failed. dev's version cannot pass at all.
src/omnibase_infra/utils/util_runtime_packages.py	main	main-only; no competing dev change. See the flag below — this one is carried, but it is not clean.
the two runner-health handlers	main for the env-read removal, dev for the behaviour	main removed direct environment reads from both handlers. dev never got that and still describes its own reads as grandfathered — which they are only against dev's history; measured against main they read as new, which is exactly why the promotion kept conflicting here. The removal is carried. dev's behaviour is preserved, not main's: the staleness threshold stays at dev's 4500s along with the comment explaining why (an idle runner only writes its diagnostic file on its ~50-minute token refresh, so main's 900s classified idle-but-healthy runners as zombies for most of every hour).
src/omnibase_infra/observability/runner_health/model_runner_fleet_config.py	both — union	The only file where each side had real content. main adds three configuration fields that replace the removed environment reads; dev adds three unrelated optional sub-configs from newer work. Both sets are kept. This is the one file in the merge that is deliberately not byte-identical to main, and that is correct — main simply does not have dev's newer fields yet.

Verification

• The eight files with no competing dev change are byte-identical to origin/main, so the next promotion has nothing left to conflict on in them.
• The ninth is the union described above.
• Targeted suites for the affected surfaces (runner-health observability, runner-fleet maintenance, the environment-read gate, and the runtime-package gate): 245 passed, 4 skipped. The 4 skips are a pre-existing guard for a file-locking tool that is not installed here, unrelated to this change.
• Handler-contract validator run against the merged tree: 5/5 validated, 0 failed.
• Full pre-commit hook chain passed on commit; the pre-push gate escalated to the full suite on its own (shared-module rule) and ran to completion before the push was accepted.

Flagged, carried but not endorsed

util_runtime_packages.py does not remove its two environment reads. It hides them: the module-level binding

_ENV_GET = vars(os)["environ"].get

reads exactly the same values, but routes around the gate, which matches on the literal spellings os.environ[, os.environ.get, os.getenv and so on. An indirection like this is invisible to that check by construction.

This is worth naming because the gate's own allowlist explicitly rejects the pattern — one of its entries reads "Formalizing the allowlist entry rather than duplicating that read through a new indirection layer." The correct shape is either a named allowlist entry or resolution through the config overlay, the way the two runner-health handlers in this same merge were fixed.

It is carried here rather than fixed, for one reason: it is already shipped on main. Reverting it on the dev side would re-open the exact promotion conflict this PR exists to close, and would do it in a file where the gate then fires. Fixing it properly means changing both branches, which is its own change with its own test surface — filed as follow-up rather than smuggled into a backmerge.

Known red, disclosed

tests/ci/test_env_parity.py::test_k8s_bound_keys_are_bound_in_compose fails here exactly as it fails on origin/dev. This PR neither introduces nor fixes it; the fix is open as #2740. Nothing here narrows, skips, or reclassifies that test.

Evidence-Source: OCC#6661
Evidence-Ticket: OMN-16041

[coderabbitai]

Warning

Review limit reached

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

Your current included review allowance is based on your included PR review attempts over the past 7 days.

Next review available in: 33 minutes

Limit details: You’ve used the included review currently available. Your 112 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

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 within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7b73627e-7c92-4b09-bff6-93f85d69a8df

📥 Commits

Reviewing files that changed from the base of the PR and between b99e1a9 and 49ff6be.

📒 Files selected for processing (11)

• .github/required-checks.yaml
• .github/workflows/artifact-reconciliation-webhook.yml
• .github/workflows/deploy-gate.yml
• .github/workflows/env-parity.yml
• scripts/validate_handler_contracts.py
• src/omnibase_infra/nodes/node_runner_fleet_health_compute/contract.yaml
• src/omnibase_infra/nodes/node_runner_fleet_health_compute/handlers/handler_runner_fleet_health_evaluate.py
• src/omnibase_infra/nodes/node_runner_health_snapshot_effect/contract.yaml
• src/omnibase_infra/nodes/node_runner_health_snapshot_effect/handlers/handler_runner_fleet_snapshot.py
• src/omnibase_infra/observability/runner_health/model_runner_fleet_config.py
• src/omnibase_infra/utils/util_runtime_packages.py

---

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

[onexbot-occ-writer]

OCC autobind did not mint a companion for this PR: no changed-file candidate could be proven RED against the merge base, and emitting a PR-existence probe instead would be non-falsifiable evidence (OMN-15247). Hand-authored evidence is required.

[github-actions]

✅ Hostile Reviewer — PASSED

Blocking findings (critical): 0
Total findings: 0
Models succeeded: qwen3-review,qwen3-review-b

---

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)