Add Batch Processing CLI commands

* Fix project search membership filter type

* Bump SDK version to 1.4.3

Expose the four public auto-label endpoints already used by the Roboflow
MCP: list the foundation-model catalog, preview one image for free, start
a job over a batch, and poll job progress.

- rfapi: list_autolabel_models, preview_autolabel, start_autolabel_job,
  get_autolabel_job (pass-through, no client-side model whitelist)
- Workspace.autolabel_models / autolabel_job
- Project.autolabel / autolabel_preview / autolabel_job; Roboflow-trained
  models are sent as custom_roboflow with modelId in modelOptions
- roboflow autolabel models | preview | start | job
- util.autolabel_utils shared by SDK and CLI (image payload from URL,
  local file or base64; model_type resolution)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

- JSON options accept @file references via the shared train parser
- Auto-label adapters use their own response helper over a generic
  JSON-or-raise implementation

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

The public signature is `{"class name": "text prompt"}`, but the API's
object form means the opposite — `normalizeOntology` treats the key as
the prompt and the value as the class, which is the `CaptionOntology`
shape the labeling worker consumes. Passing the dict straight through
therefore inverted every non-identity ontology: `ontology={"cat": "a
cat"}` prompted the model with "cat" and wrote the annotations under the
class name "a cat". The `--class` path built an identity map, which is
symmetric, so the tests never caught it.

Serialize through `ontology_payload` instead. The list form names both
sides, so nothing has to be inferred from key order; the backend already
normalizes it on both the preview and the start path, and it is what the
web app sends. `Project.autolabel` also accepts a plain list of class
names now, matching `autolabel_preview`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…mpts

The class-keyed dict the previous commit settled on cannot express the
case the API's ontology exists for: several prompts collapsing to one
output class, e.g. "kitten" and "tabby" both labeled `cat`. A dict has
room for one prompt per class because its keys are unique.

So accept the explicit list on the way in too, alongside the dict and the
plain list of class names. It is the same shape already used on the wire,
so this is one shape fewer to think about rather than one more.

Reject the mirror case while we are here: two classes claiming one prompt.
The API keys its ontology by prompt, so it keeps whichever class came last
and drops the other, and the job then never labels that class with nothing
in the response to say why. `ontology_payload` names the collision instead,
and the CLI reports it before any network call rather than letting the
ValueError escape as a traceback.

`--ontology` accepts a JSON array as well as an object; `_parse_json_flag`
grew an opt-in `allow_list` for that and stays object-only everywhere else.

Settles the direction question the last two commits worked around. The
API's ontology is `{prompt: class name}`, and so is the CaptionOntology
the labeling worker consumes, so the SDK and CLI now take that shape
directly instead of translating a class-keyed one into it.

That direction is the useful one, not an accident of the API: prompts are
the unique side, so several of them can collapse onto one output class,
`{"kitten": "cat", "tabby": "cat"}`. A class-keyed object has room for one
prompt per class. The previous commit reached for a [{class, prompt}] list
to get that expressiveness back, which the prompt-keyed object gives for
free.

Dropping the translation drops what surrounded it: the wire form, the
entry-list shape, the guard against two classes claiming one prompt (a
duplicate prompt is now impossible, it is a dict key), and the `allow_list`
opt-in `_parse_json_flag` grew for the array. Net 87 lines lighter.

A plain list of class names still works and still means "prompt each class
with its own name".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Five fixes from Iuri's review, in the order he listed them.

A mistyped --image path was silently sent as base64. image_payload now
expands ~, and anything that is neither a URL, an existing file nor valid
base64 is rejected with "Image file not found" instead of reaching the API
and failing there with a generic inference error.

An unreadable image file escaped as a raw traceback, since the payload was
built inside the operation _run wraps and _run only catches RoboflowError
and ValueError. preview now builds the payload before resolving the
project, so both the not-found and the OSError case print a structured
error, and they fail before any network call.

`autolabel job` could not find a job `autolabel start -p other-ws/proj`
had just created, because start derived the workspace from the shorthand
and job only read --workspace or the default. job now takes the same -p
and resolves the workspace the same way.

preserveExistingAnnotations was not exposed, and the server default
(false) replaces annotations already on the batch images. Added
`preserve_existing_annotations` to rfapi.start_autolabel_job and
Project.autolabel, and `--preserve-existing` to the CLI.

The handler re-implemented the credential resolvers and diverged: a
missing default workspace exited 1 where the CLI contract says 2. It now
uses resolve_ws_and_key, and the project variant is lifted from
annotation.py into _resolver.py as resolve_project_context so there is one
copy instead of three. Folding _models into _workspace_command fell out of
the same change.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Add hosted auto-label support to the SDK and CLI