[jonahgabriel]

What

OCC companion for OmniNode-ai/omninode_infra#1280 — the server half of
OMN-18081, bound by hand (union-resolve) onto the same ticket contract that
OCC#8800 established for the omniweb half.

OCC#8800 merged while this was being written, so this appends to the contract on
dev rather than to that PR's branch. Hand-minted because autobind is not
producing companions in this window (OMN-18073).

Why there is a server half at all

OMN-18081 opened stating "no omninode_infra change is needed". The operator
then clarified the intent, in-session 2026-09-09T~14:27Z:

"It seems like the input is fine but it should be for the label for the API key
so that people can mint more than one API key."

That reframed the ticket from "the label input is missing" (it was not) to "can a
customer actually hold several labelled keys", and the rewritten scope asked the
gateway to be read rather than assumed. Three suspects; one was real.

Suspect	Verdict
Per-tenant key cap	None exists. MAX_API_KEY_LIMIT is a pagination bound enforced in list_api_keys, not in the mint.
Auto-mint revoking or replacing an incumbent	Does not happen. _ensure_default_api_key returns early when the tenant holds any key; the mint's body is a single INSERT.
Unique (tenant_id, name) refusing a duplicate label	Real, and its refusal was unreadable.

A key with a distinct label was never blocked by any of the three — the
headline intent already worked. But uq_tenant_api_keys_tenant_id_name_active's
correct refusal of a duplicate reached the customer as a bare 500: it raised
ApiKeyValidationError, the router caught nothing, and there is no
add_exception_handler for any ApiKeyError in the service, so omniweb rendered
its no-detail fallback. #1280 makes it a typed 409 with a customer-readable
sentence.

Contract change

Appended, never edited, and verified empirically rather than asserted: the
existing entries' contract_entry_sha256 values were recomputed after the append
(and after the yaml hook's reflow of the new entry) and are byte-identical to the
values already carried by the merged receipts. That is precisely the
append-stability OMN-13888 exists for, and the reflow is the case the per-entry
hash is defined over parsed YAML to survive.

The new receipts' whole-file contract_sha256 is computed for the current bytes.
The older receipts' copies of that field are now stale, which is harmless and
expected — it is only ever the FALLBACK, consulted when a receipt carries no
entry hash, and both of those carry one.

Receipts

Both carry real probe output, run at c911a5d071f45f189383c9243d2a436896e778fd:

• command — #1280 open on OmniNode-ai/omninode_infra.
• test_passes — 9/9 in test_omn_18081_duplicate_key_label_refusal.py.
  RED baseline at origin/dev c6f20f78: 4 of 9 fail. The other 5 pass at
  baseline by design — they assert the two absences above, which were already
  true and which the ticket asked to verify rather than assume. Each carries a
  positive control, so a zero is a fact about the code and not a mis-spelled
  probe.

Regression control: the six neighbouring suites were run before and after and
their failure sets diffed — pre-existing env-dependent failures unchanged, zero
new failures. No stderr was suppressed on any probe.

Not bound here

AC4c and the staging readback on onex-dev. They cannot be proven before #1280
merges and reaches the cluster, and binding them now would be a receipt for work
that has not happened.

Rule 24, stated rather than implied: the .201 compose dev lane runs no
onex-api and no dashboard, so there is no lab surface for this path. No lab pass
is claimed. The staging readback is the proof.

No credential was rotated, re-issued, revoked or minted; no secret value was read
or printed; no cluster object was mutated.

Ticket: OMN-18081
Evidence-Ticket: OMN-18081