fix(desktop): let a relay's model catalog answer for itself

[Joob1n]

Summary

Adding a custom relay asked for a model id before the connection existed, made it required, then fetched the endpoint's catalog moments later and discarded any error from doing so. The user typed a model they had no way to know, and if the fetch then failed they were told nothing — an empty picker and no explanation.

The field's own help text already described the intended behaviour:

保存后仍会自动拉取模型目录 · Maka still fetches the model catalog after saving.

So the requirement contradicted the copy printed directly beneath it.

Two changes:

The model id is no longer required. Checked against the registry rather than assumed: of 59 providers, 55 ship fallback models and 55 answer discovery — 4 exclusively, which are the relays. None is left with no way to name a model, so demanding one up front buys nothing.

A failed fetch is reported for relays too. It was swallowed on the reasoning that a relay might not implement discovery. But a relay is the endpoint most likely to be pointed somewhere wrong, and the toast plus endpoint-troubleshooting hint already existed for every other provider — relays were the one case excluded from the diagnostic they needed most.

The placeholder now says the field can be left empty; the help text says a model id is needed only when the endpoint serves no catalog.

What this deliberately does not do

Fetch the catalog before the connection is created, so the field could be a picker instead of free text. fetchModels takes a connection slug, so discovery cannot run until the connection exists — a pre-create probe is a new Runtime Host operation, a new IPC surface, and a compatibility epoch bump. Filed as #3442 with the decisions it needs settled first.

Verification

npm run build, lint, format:check, typecheck. Suites: @maka/desktop 1034, @maka/core 587.

Registry claim verified by enumerating PROVIDER_REGISTRY rather than reasoning about it:

fallback + discovery: 51    fallback only: 4    discovery only: 4    neither: 0

The "neither" count is what makes the requirement safe to drop — I added a providerRequiresHandTypedModel predicate first, found it returned false for every provider in the registry, and removed it rather than ship a branch that can never be taken.

Not run: Windows and Linux. This is renderer-only.

Review focus

Whether reporting relay discovery failures is right. It is a behaviour change for the noisier direction: a relay that genuinely serves no catalog now shows an error toast on creation where it previously showed nothing. My reading is that this is correct — the connection is still created, the message names the endpoint, and silence was indistinguishable from success. If the project would rather relays stay quiet, the alternative is a softer notice rather than restoring the swallow.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code — traced the existing discovery path, made the change, and ran the verification above. Generated-by is on the commit. Reviewed and submitted by the contributor of record.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No