chore(OMN-17802): pin omnibase-core 0.47.14 and cut the omnibase-infra release omnimarket needs

[jonahgabriel]

OMN-17802.

omnimarket#2555 (squash c68676e2) pinned omnibase-core>=0.47.14,<0.48.0, but no published omnibase-infra release pins core 0.47.14 -- dev still pinned 0.47.13, so omnimarket's Release on Merge has no resolvable dependency graph (pip has no solution for omnibase-infra>=0.38.22 + omnibase-core==0.47.14). This bumps the pin so the next omnibase-infra release unblocks it.

Changes

• pyproject.toml: omnibase-core==0.47.13 -> 0.47.14 (both the [project].dependencies floor and the [tool.uv] override-dependencies entry)
• uv.lock: re-locked from the PyPI registry only, no editable/source fallback (confirmed no [tool.uv.sources] override for omnibase-core/spi/compat exists)
• docker/runners/runner-image.lock.json: regenerated identity/shared-env digests via scripts/ci/runner_image_identity.py --mode generate
• src/omnibase_infra/runtime/version_compatibility.py: _FALLBACK_MATRIX min_version 0.47.13 -> 0.47.14 (last-known-good fallback used only when pyproject.toml is unavailable)
• tests/fixtures/seams/core_release/0.46.11_expected_symbols.json: core_version field updated to 0.47.14 so tests/unit/runtime/test_seam_released_core_pin.py doesn't flag a version mismatch

Mirrors the precedent shape of the OMN-18295 (0.47.13) and OMN-18202 (0.47.12) pin-bump PRs.

Version

dev's [project].version stays at 0.38.27 -- it is already ahead of the latest published tag (v0.38.26), so this PR does not bump it. Cutting a release from this dev HEAD after merge publishes 0.38.27 carrying the 0.47.14 pin, which is what omnimarket's Release on Merge needs. Left to release automation / a follow-up manual dispatch, not to this PR.

Lab-first note

A dependency-pin bump has no runtime behaviour change. The lab proof is the dev-lane rebuild the Runtime Rebuild Trigger fires on merge; that trigger run id will be cited once available. Separately, omnimarket's own rebuild trigger for c68676e2 is stuck queued on a runner-label issue the orchestrator is handling.

Note on a duplicate automated PR

OmniNode-ai/omnibase_infra#3546 (app/onexbot-occ-writer, dependency-cascade automation) carries the identical pin/lock/runner-image diff but is red: its OCC preflight fails with reason: pr_ticket_mismatch because it cites ticket OMN-18205 with no PASS receipt bound to PR #3546 or its commit SHAs. This PR supersedes it via a ticket (OMN-17802) whose autobind can bind correctly. #3546 should be closed once this merges to avoid a stale duplicate.

Evidence-Ticket: OMN-17802
Evidence-Source: OCC#9591

[github-actions]

Hostile Reviewer — adversarial findings (OMN-17492)

Models succeeded: glm-review
Models failed: codex
New finding threads: 5
Deduped (already posted on this PR): 0
Nit-level findings suppressed: 1

The model is the FINDER, never the gate: merge is gated only by the
deterministic Hostile Review Thread Gate, which blocks while
hostile-reviewer threads are unresolved. Resolve each thread after
addressing (or rejecting, with a reply) its finding.

Findings demoted from threads (anchor rejected)

• [MAJOR] hostile-reviewer (glm-review)

  Seam fixture surface unchanged despite core version bump | The diff updates the fixture's core_version field and comment but leaves the modules/symbols inventory identical. The fixture's stated purpose is to fail loudly when the consumed surface changes. Either 0.47.14 introduces no consumed-symbol changes, in which case the fixture provides no verification value for this bump and the diff's rationale is untested, or the surface did change and the fixture was not re-recorded after running the seam test as t

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MAJOR] hostile-reviewer (glm-review)

  New core symbols from merged PRs not validated anywhere in diff | The pyproject comment indicates this pin line pulls core #1439 (terminal delegation classes) and #1440 (runtime_fanout_resolver, OMN-14403). No test, fixture, or call-site change in the diff consumes or exercises runtime_fanout_resolver or the delegation classes. Bumping the dependency version alone does not establish the new API works against infra's dispatch path. If no consumer exists yet, the bump is unverifiable and the seam fixture (whi

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MINOR] hostile-reviewer (glm-review)

  Runner image lock digests rotated without image_version bump | identity_digest and shared_env_digest are updated but image_version stays at 7. If image_version functions as the human-facing cache/rebuild discriminator for downstream image consumers, a stale version paired with changed content digests creates ambiguity about which image corresponds to which lock state. If identity_digest is authoritative this is cosmetic, but the dual-mechanism without a stated precedence rule invites drift. | Evidence: "ima

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MINOR] hostile-reviewer (glm-review)

  Stale comment describes published release as pre-release | The adjacent comment asserts the pin pulls a pre-release of #1440, but the fixture change declares source: pypi for the same version, and the uv.lock entry resolves from the public registry. The comment now misdescribes the resolution source. Comments that contradict the lockfile erode the documentation's reliability for the next bump author. | Evidence: # merged core #1440 (runtime_fanout_resolver, OMN-14403) pre-release --

  #1440 is a strict desc

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MINOR] hostile-reviewer (glm-review)

  Fallback matrix bump untested against compatibility gate | The fallback min_version moves to 0.47.14 but the diff contains no test update asserting the new constraint is enforced (e.g., a runtime version check rejecting 0.47.13). If _FALLBACK_MATRIX is consumed by a startup compatibility gate, that gate's behavior change is untested; if it is dead data, the edit is noise. Either way the diff does not demonstrate the constraint takes effect. | Evidence: package="omnibase_core",

  •    min_version="0.47.13"
    

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

[github-actions]

⚠️ Hostile Reviewer — DEGRADED (informational)

Critical findings: 0
Major findings: 1
Total findings: 6
Models succeeded: glm-review

Note: Fewer than 2 reviewer models succeeded. Degraded results are informational (OMN-8468/OMN-8524) and do not block merge. Error: cli_review exit 2 (fewer than 2 models succeeded — partial/total outage)

---

Semantics (OMN-17492 — the model finds, thread resolution gates)

Surface	Meaning	Blocks merge?
Review threads	Per-finding, posted by the reviewer	No (informational)
Hostile Review Thread Gate	Deterministic: unresolved hostile-reviewer threads exist	Fails until resolved (not yet a required context)
degraded verdict	Fewer than 2 models succeeded (infra)	No

Powered by omniintelligence.review_pairing.cli_review — multi-model adversarial review: qwen3-review, qwen3-review-b, glm-review (OMN-8468/OMN-8524/OMN-17492)

[github-actions]

Hostile Reviewer — adversarial findings (OMN-17492)

Models succeeded: glm-review
Models failed: codex
New finding threads: 6
Deduped (already posted on this PR): 0
Nit-level findings suppressed: 0

The model is the FINDER, never the gate: merge is gated only by the
deterministic Hostile Review Thread Gate, which blocks while
hostile-reviewer threads are unresolved. Resolve each thread after
addressing (or rejecting, with a reply) its finding.

Findings demoted from threads (anchor rejected)

• [MAJOR] hostile-reviewer (glm-review)

  Seam fixture updated without evidence of surface verification | The diff edits only the version strings and comments in 0.46.11_expected_symbols.json; the module symbol lists and field types are unchanged. The fixture's own stated procedure requires re-running the seam test after a core bump and recording the surface 'only after confirming every consumer still type-checks.' A core minor bump (0.47.13 -> 0.47.14) carrying new delegation and fanout resolver classes would plausibly alter importable symbols; an

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MINOR] hostile-reviewer (glm-review)

  Fallback matrix boundary tests cover only the lower bound | The new integration tests assert rejection of 0.47.13 and acceptance of 0.47.14, but never exercise the upper bound max_version=0.48.0. A copy-paste or parsing defect in the max constraint (e.g., 0.48.0 rejected when it should be accepted, or 0.49.0 accepted) passes these tests. | Evidence: test_fallback_matrix_rejects_the_previous_core_pin / test_fallback_matrix_accepts_the_release_core_pin; _FALLBACK_MATRIX defines max_version="0.48.0" | Fix: Add

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MINOR] hostile-reviewer (glm-review)

  Tests assert exact error message format, coupling to implementation string | assert errors == ["omnibase_core: 0.47.13 is incompatible (required >=0.47.14,<0.48.0)"] hard-codes the human-readable error rendering produced by check_version_compatibility. Any cosmetic reformatting of the message breaks the test without indicating a behavioral regression. | Evidence: assert errors == [
  "omnibase_core: 0.47.13 is incompatible (required >=0.47.14,<0.48.0)"
  ] | Fix: Assert on the number of errors, the

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MINOR] hostile-reviewer (glm-review)

  Fixture file name contradicts its pinned version | The file 0.46.11_expected_symbols.json now declares core_version 0.47.14. The version-in-filename convention appears violated; either the naming scheme encodes something else (unexplained in the diff) or this will mislead future maintainers resolving which fixture covers which release. | Evidence: tests/fixtures/seams/core_release/0.46.11_expected_symbols.json containing "core_version": "0.47.14" | Fix: Rename the fixture to match its pinned version or docu

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MINOR] hostile-reviewer (glm-review)

  Runner image lock digests changed with no rationale or image_version bump | identity_digest and shared_env_digest both change while image_version remains 7 and the diff contains no explanation. If shared_env_install_args and uv_version are unchanged, the digest drift implies an environment rebuild whose contents are not auditable from this diff. Downstream consumers keyed on identity_digest will invalidate caches with no visible cause. | Evidence: - "identity_digest": "091720042cd2b75a36a2c35b4ab02645",
  +

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).

• [MINOR] hostile-reviewer (glm-review)

  Fallback matrix max_version vs exact pin creates a support window ambiguity | pyproject.toml pins omnibase-core==0.47.14 exactly, while _FALLBACK_MATRIX permits >=0.47.14,<0.48.0. The fallback therefore accepts environments the pin forbids and vice versa in spirit. The plan does not state whether 0.47.15+ is a supported configuration; a future patch bump that only updates pyproject/uv.lock but not the fallback matrix would leave the two sources diverging silently. | Evidence: "omnibase-core==0.47.14" in dep

  Resolve this thread when addressed — the Hostile Review Thread Gate blocks while hostile-reviewer threads are unresolved (OMN-17492).