Custom relay: no way to see the model catalog while filling in the form that needs it

## Problem

Adding a custom relay asks for a model id as free text. Maka fetches the endpoint's catalog immediately after the connection is created, so the value the user typed is usually replaced seconds later — they were asked to guess something the app was about to find out.

The ordering is what forces it: `fetchModels` (`bridge-contract.d.ts:802`) takes a connection slug, so discovery cannot run until the connection exists. The form therefore has nothing to offer while the user is filling it in, and free text is the only honest control for a value nobody knows yet.

The immediate harm is addressed separately — the field is no longer required, and a failed fetch is now reported instead of swallowed. What remains is that the user still cannot see the catalog at the moment they are choosing from it.

## What this needs

A probe: given a base URL and credentials, list the models that endpoint serves, without persisting a connection.

That is a new operation, not a new caller of an existing one. Sketch of the surface it would cross:

- a Runtime Host operation that performs discovery against supplied connection material rather than a stored connection
- the preload/IPC surface to reach it
- a "fetch models" action in the add form, turning the model field into a picker once it returns
- `RUNTIME_HOST_COMPATIBILITY_EPOCH` — a new wire operation is a decode change in the new-Client-against-old-Host direction

## Decisions worth settling before implementation

- **Where the probe runs.** Discovery from the Host keeps credentials off the renderer, matching how `fetchModels` already works. It also means the probe inherits the Host's network path, which is the one that matters — a relay reachable from the renderer but not the Host would otherwise pass the probe and fail in use.
- **What it may keep.** Nothing, ideally: a probe that writes no connection and caches no credential has no cleanup story and no half-created state to reconcile. That constrains the operation shape.
- **What a failed probe means.** It must not block creation. An endpoint that serves no catalog is a supported configuration — that is exactly when a hand-typed model id is the right answer.

## Not in scope

Changing how discovery works for connections that already exist. `fetchModels` and the "update models" action in the connection detail are unaffected.

Refs #3443

Start with fetchModels in bridge-contract.d.ts:802, then trace the Runtime Host and preload/IPC surfaces to the add form. Decide how a non-persisting probe carries credentials and models, including the compatibility epoch change. Done means the form can fetch and choose catalog models without saving a connection, while failed discovery still permits manual entry and existing-connection discovery remains unchanged.

Written by the indexing model from the issue text.