Connect a local model runtime from config, and ask it what it serves

[its-janghoon]

Pointing Redrob Code at Ollama, LM Studio, llama.cpp or vLLM was not possible. ConfigProviderPlugin
refused to let a config file introduce any new AI-SDK provider, and its comment says exactly why: an
arbitrary npm package reaches DynamicProviderPlugin and gets installed and imported, which is arbitrary
code execution from a config file. That reasoning is correct and this change does not weaken it.

It blocked one case it did not need to. Every local runtime worth pointing at speaks the OpenAI-compatible
wire protocol, and @ai-sdk/openai-compatible is ALREADY the trusted, pinned package the console provider
itself uses -- so a local provider needs no new package at all. The hole opened here is exactly that
shape and no wider.

=== The gate ===

config/plugin/local-provider.ts decides it, and both conditions are necessary:

• The package is EXACTLY @ai-sdk/openai-compatible. Anything else keeps the old refusal, so the
  install-an-arbitrary-package path stays shut. A local ADDRESS does not buy an arbitrary package.
• The URL is loopback or private: 127/8, ::1, localhost, *.localhost (RFC 6761), 10/8, 172.16/12,
  192.168/16, 169.254/16, fc00::/7, fe80::/10. Without this, opening the door for local runtimes would
  also let a config file point a brand-new provider at any host on the internet -- quietly routing
  prompts, and whatever is in them, somewhere the user never chose.

A URL that does not parse is NOT local. That direction is deliberate: the cost of guessing wrong the other
way is a config file reaching the open internet, so anything unrecognised is refused.

=== Asking the runtime what it serves ===

config/plugin/local-models.ts fetches the OpenAI-standard GET <base>/models and adds those ids. A
hand-written model list goes stale the moment the user pulls a new model, which with Ollama is a one-line
command people run constantly.

Three properties, each chosen against a specific failure:

• BEST-EFFORT. A local runtime that is not running is the normal state of a laptop, not an error. A
  failed fetch leaves the provider exactly as config declared it and logs at debug. Anything louder
  would make every start of the CLI complain about a model server the user is not using today.
• RE-CHECKS THE ADDRESS RULE. This is an outbound request built from a config file, so it re-applies
  isLocalEndpoint rather than trusting the introduce gate. Two independent checks of one rule is the
  point: a later change that loosens one must not silently turn startup into a request to anywhere.
• FAST TO FAIL. Two seconds, because the premise is a server on this machine or this LAN. The console's
  fetch can afford ten over the internet; waiting that long for loopback only delays the CLI when the
  runtime is down.

Model names are only DEFAULTED from the id, never overwritten -- a config file that gave a model a
readable name meant it, and the raw id is what that name replaced. Listing entries are decoded ONE AT A
TIME, because all-or-nothing decoding is what made the console catalog silently collapse to its six-id
fallback when a single entry was unexpected.

The fetch happens BEFORE the catalog transform, not inside it. ctx.catalog.transform takes
void | Effect<void, never, never> -- no requirements, no errors -- so HTTP cannot live there. Rather
than work around that, the providers are read from config directly, where they are declared anyway, and
the transform applies what is already in hand. That also drops an ordering dependency on whichever plugin
put the provider in the catalog.

=== Verification ===

The refusals carry the weight, because a predicate that is too permissive lets a config file reach the
internet while one that is too strict merely fails to find Ollama, which the user notices at once.

• local-provider.test.ts (16): public addresses, the boundaries just outside each private range
  (172.32, 172.15, 11.0, 192.169), hostnames that merely CONTAIN a local name
  (localhost.evil.example), non-http schemes, and unparseable input failing closed.
• local-models.test.ts (6): URL joining with and without trailing slashes, and the re-checked gate.
• local-models-discovery.test.ts (3): the plugin against a REAL http server -- a stubbed client would
  only assert my own understanding of the wire format back at me. It pins that the request is actually
  made (GET /v1/models), that the served ids reach the catalog, that a public address produces ZERO
  requests, and that an unreachable runtime leaves the provider intact.
• provider.test.ts (+3): a local provider is introduced, another package is refused, and a public
  address is refused even with the trusted package.

One of my own tests was wrong and the code was right: I asserted http://10.0.0/v1 should be refused, but
the URL parser normalises it to 10.0.0.0, which genuinely is private. Refusing it would refuse a real
private host, and this predicate is about where the request lands. The public counterpart (11.0.0) is
pinned as refused alongside it.

config group 79/79, core typecheck clean.

=== Known gap, not addressed here ===

I could not verify this through a running server: serve did not load a providers block from a project
redrob.json, a .redrob/redrob.json, or an isolated REDROB_CONFIG_DIR. The config itself is fine --
decoding that exact object against Config.Info succeeds and yields the provider -- and providers is
not a V1 key, so it takes the V2 path. So the loading problem is separate from this change, which is why the
verification above goes through the plugin directly. Worth its own look: config.ts's loadFile drops a
file silently on a decode failure (if (!info) return), which is the same no-error-no-warning failure a
neighbouring comment in that file already complains about.