Create or append a version on a user-owned semantic verifier.
A semantic verifier is a single judgment ("does this output satisfy this
criterion?") evaluated by an LLM judge. Verifiers are private and
owner-scoped. Workflows reference them by ``verifier_id`` (or
``verifier_id@version``). You cannot deploy a **new** verifier whose
``name`` matches an active platform ``scope=system`` verifier: those
definitions are server-owned, never listed or fetched, and only
executable through ``run_verifier``.
Versioning: the first deploy with a given ``name`` creates the verifier
at version 1. Re-deploying the same ``name`` appends a new version and
requires ``expected_version_token`` from the latest known version
(returned by deploy/list/get). A new verifier must omit the token; an
existing one without a token returns Conflict.
Input contracts:
- ``text``: ``input_fields`` required, ``media_url`` rejected.
- ``text_image``: ``input_fields`` plus ``media_url`` required at run time.
- ``image``: ``input_fields`` empty, only ``media_url`` at run time.
Few-shot examples (3 to 10 typical) calibrate the judge; each example
must match the contract (text-only inputs, text+image, or image-only).
Returns: ``{verifier_id, name, current_version, version, version_token,
status, input_contract, config_hash}``. Persist ``version_token`` for
the next re-deploy.