Say when /model does not recognise the id (#831)

[yogthos]

Closes #831. Sequel to #825/#826.

What was wrong

resolve_model_switch ends in a deliberate permissive fallthrough: an id that
matches no configured alias and no known model family returns Keep, which is
what lets /model claude-opus-6 work on release day, before dirge knows the id.
#826 narrowed the trap to genuinely unknown strings rather than closing it, on
purpose — and that is worth keeping.

But Keep is also what /model off gets, and the report is a real slip: off
is a valid argument to both /effort off and /agent off, and there is no
/model equivalent of "go back", so reaching for it is natural. It reports
success and leaves session.model = "off", with nothing said until the next
request 400s.

What this does

Keeps applying it, and says so. The unrecognised case now returns its own
ModelSwitch::KeepUnrecognized, carried through to ModelRoute::Active { model, recognized }, and /model appends one clause:

switched to model: off  (unrecognised — your provider may not serve it)

The clause never fires on the common paths — a configured alias, an exact pin,
the gateway-dialect rule, or an id whose family model_family knows — so in
practice it fires on typos and on genuinely new models, where "dirge does not
recognise this" is simply true.

On what the note claims. dirge cannot know whether an id is valid; only the
provider can. It knows whether it recognises it. Those come apart for a
new-but-valid id, so the clause asserts recognition and leaves the consequence
conditional ("may not serve it") rather than predicting a failure.

The rejected alternative from the issue — suppressing the note when the id
"looks like" a model — is not implemented, for the reasons given there: it would
pass claude-opuss-5 silently, which is the case most worth catching.

Same clause on the ACP /model path, which shares the routing decision.