fix(OMN-18294): read the gateway's declared prompt ceiling and stop discarding its field-level errors

[jonahgabriel]

Closes OMN-18294 (client half). The gateway half is omninode_infra#1418 and cites the same ticket.

What was wrong

Dogfood round 2 (2026-09-13) submitted a real 58,368-character standup prompt through onex cloud delegate against the onex-lab-dogfood tenant and got back a sentence it could do nothing with:

[ONEX_CORE_007_INVALID_INPUT] the gateway refused the request to submit
the delegation with 400. Gateway detail: payload does not conform to the
workflow contract

Two client-side defects sit behind that sentence.

The client discarded the answer it was given. This is the larger one. The gateway's 400 has always carried field-level errors merged into the body next to detail, and on this refusal that list said exactly what was wrong: {"field": "prompt", "message": "must be at most 65536 characters"}. _detail() read detail alone and threw the rest away. The generic sentence the customer saw was not the gateway being unhelpful; it was this client dropping the helpful half. Every field-level error is now rendered, and all of them at once, because fixing one violation and resubmitting to find the next is not a workflow to hand somebody. This is the half that makes every future contract violation legible, not just the one size rule this ticket happened to find.

The client had no way to know the limit before spending a round trip. submit now reads the ceiling from the gateway's own advertised contract, GET /v1/workflows/contracts, and refuses locally naming both the limit and the measured size. Neither number alone is actionable: the ceiling does not say how far over you are, and the size does not say what you broke.

What this deliberately does not do

It never hardcodes the limit. A client-side number the server never agreed to would be the same undeclared, unreadable limit this ticket exists to remove, relocated from the server to the laptop. A test advertises a ceiling of 1024 from the fake gateway and asserts the client obeys that, precisely so a future hardcoded constant cannot pass.

It never invents one when the gateway is silent. An older gateway, a 404, or a discovery outage all mean the ceiling is unknown. The submission then goes out and the gateway decides, which is correct: a default would refuse work a newer gateway would have accepted. Discovery is a legibility improvement, never a new dependency of submission, and two tests pin that.

It costs one request per CLI run, not one per submission. The gateway meters 30 requests/minute per tenant on the discovery plan and the poll loop already spends a good share of that budget, so the answer is cached per transport — the unknown answer included, or a gateway that has already said it cannot say would be re-asked on every submit.

Existing tests changed, and why

Three transport tests recorded every request as though it were the submission. They now answer the contract read separately and assert on the submission, which is what each was about. The submission's wire shape is unchanged and test_submission_wire_shape_is_unchanged pins it.

Tests

tests/unit/cloud/test_omn_18294_prompt_limit_client.py — 6 RED before this change, covering the local refusal, the contract-resolved ceiling, the discovery cache, and the two dropped-errors cases. 13 green after.

tests/unit/cloud/ + tests/unit/cli/test_cli_cloud.py: 81 passed. ruff check and ruff format clean. mypy --strict clean on the changed module.

Not covered

The lab readback is taken after merge on the rebuilt onex-lab lane, as one real onex cloud delegate of the same 57KB prompt as the dogfood tenant, and recorded on the ticket as dod_evidence. Until the gateway PR merges and the lane is rebuilt, this client will find no discovery endpoint on the lab and will defer to the gateway — which is the documented unknown-ceiling path, not a failure.

Evidence-Ticket: OMN-18294
Evidence-Source: OCC#9330

[github-actions]

✅ Architectural Review — PASSED

Errors: 0
Warnings: 0

What this checks

Rule	Description
ARCH-TOPIC-001	No hardcoded Kafka topic strings in handler code
ARCH-DI-001	No event_bus=None bypass
ARCH-DI-002	No direct Handler instantiation outside workflow_runner/adapters
ARCH-DI-003	No reinvented DI containers
ARCH-TOPIC-002	contract.yaml topics follow `onex.{cmd

---

No architectural violations found.

Static architectural lint — no model inference (OMN-14176).

[github-actions]

✅ Hostile Reviewer — PASSED

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

---

Gate semantics

Verdict	Meaning	Blocks merge?
passed	>=2 models succeeded, no critical/error findings	No
blocked	CRITICAL or ERROR findings found	Yes
degraded	Fewer than 2 models succeeded (infra unavailable/timeout)	Yes (OMN-15110)

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