Plugin configured by a non-existent directory path is dropped with zero diagnostics

Description

A plugin entry pointing at a directory path that does not exist is discarded during config load with no log line at any level — not even WARN. The provider it would have registered is simply absent, and the first symptom is a ProviderModelNotFoundError at request time, potentially days later.

This is adjacent to #46551 but a different code path with a worse outcome. #46551 covers configured file paths, which at least emit level=WARN message="configured plugin path must be a directory". A non-existent directory target emits nothing whatsoever.

Verified both branches on the same machine, same version:

Config entry	Diagnostic emitted
/tmp/pluginrepro/nope.js (file, #46551 case)	WARN line
./plugins/vendor/does-not-exist-anywhere-0.0.1 (missing dir)	none

$ opencode run --print-logs 'hi' 2>&1 | grep -c 'does-not-exist-anywhere'
0

Zero occurrences of the offending path across the entire log stream, including --print-logs.

Why this matters

This silently degrades model routing rather than failing. On my install a vendored plugin directory was removed during an unrelated cleanup. The config still referenced it, so:

1. The plugin never loaded; its provider was never registered.
2. Every agent configured against that provider fell through to the next entry in its fallback list.
3. Sessions ran for hours on an unintended fallback provider, which then hit Usage credits are required for long context requests and All credentials are cooling down.
4. Only then did ProviderModelNotFoundError: Model not found: <provider>/<model> surface.

Nothing at startup indicated the configured plugin was missing. The config was broken from the first second and OpenCode reported it as healthy.

Steps to reproduce

mkdir -p /tmp/pluginrepro && cd /tmp/pluginrepro
cat > opencode.json <<'EOF'
{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["./plugins/vendor/does-not-exist-anywhere-0.0.1"]
}
EOF
opencode run --print-logs 'say HI' 2>&1 | grep -c 'does-not-exist-anywhere'

Observed: 0. Config loads, message=loading path=/private/tmp/pluginrepro/opencode.json is logged, and the missing plugin is never mentioned.

Expected: a diagnostic naming the unresolvable path. A configured plugin target that cannot be resolved is a config error, not a silent no-op.

Suggested fix

In the same resolver #46551 touches (packages/core/src/config/plugin/source.ts), the directory branch appears to return Option.none for a non-existent target without logging. Two options, in preference order:

1. Fail loudly at startup — surface unresolvable plugin entries as a config error, consistent with how other invalid config is treated.
2. At minimum, log it — emit at least the same WARN the file branch emits, so --print-logs can diagnose it.

I'd also suggest that when a plugin fails to resolve, a model reference whose provider prefix that plugin would have supplied should produce an error naming the plugin as the cause, rather than an opaque "model not found".

Plugins

@omniroute/opencode-plugin@0.2.1, oh-my-openagent@5.0.0-beta.34, plus local file plugins.

OpenCode version

1.18.30

Operating System

macOS 26.6.2 (Darwin 25.6.0, arm64, Apple M1)

Terminal

xterm-256color; Bun 1.4.2