Summary

On dual-stack hosts (notably macOS), localhost resolves to both ::1 and 127.0.0.1 with IPv6 tried first. Local LLM servers (Ollama / vLLM / LM Studio / Lemonade) installed via the standard scripts bind IPv4 only, so reqwest's first connection attempt to [::1]:<port> is refused instantly. Happy Eyeballs fallback to IPv4 isn't reliably triggered for connection-refused (vs. timeout), so the probe fails outright and the daemon spams:

WARN Configured local provider offline provider=ollama error="error sending request for url (http://localhost:11434/api/tags)"

…even though curl http://localhost:11434/api/tags works fine (curl explicitly does the IPv6→IPv4 fallback).

Repro

$ lsof -iTCP:11434 -sTCP:LISTEN
COMMAND  PID  USER  FD  TYPE  NODE NAME
ollama   ...  ...   5u  IPv4  TCP localhost:11434 (LISTEN)   ← IPv4 only

$ cat /etc/hosts | grep localhost
127.0.0.1  localhost
::1        localhost

The TCP-level reachability check at kernel/mod.rs:1754 already uses 127.0.0.1 directly (and succeeds), but the URL stored in provider_urls.ollama was http://localhost:11434/v1, so subsequent reqwest calls fail. This PR brings the URL strings in line with the reachability check.

Changes

Production code:

• PROVIDER_REGISTRY defaults for ollama, vllm, lmstudio, lemonade (librefang-llm-drivers)
• Embedding driver fallback URLs for the same three providers (librefang-runtime/embedding.rs)
• Auto-detected ollama URL injected into provider_urls (librefang-kernel/kernel/mod.rs)
• The standalone Ollama detect probe (librefang-api/routes/providers.rs::detect_ollama)
• Example URLs in the init config template (librefang-cli/templates/init_default_config.toml)

Existing test fixtures that happen to use localhost as an arbitrary input string are intentionally left alone (they're not asserting the default URL constant). The two model_catalog.rs tests that DO assert default URLs (test_set_provider_url, test_apply_url_overrides) still load from the live librefang-registry repo via resolve_home_dir_for_tests, so they are not affected by this PR — they will need updating in tandem with the registry-repo PR (see below).

Follow-up needed

The runtime probe URL (the one that actually triggered the warning the user reported) comes from ~/.librefang/registry/providers/ollama.toml, which is synced from the librefang-registry repo. A matching PR is needed there to flip those base_url fields from http://localhost:... to http://127.0.0.1:.... After both land, existing installs will pick up the fix on their next registry sync.

Test plan

• CI green (workspace build + tests + clippy zero-warnings)
• On a macOS host with Ollama running and no provider_urls.ollama override in config.toml: start daemon, confirm no Configured local provider offline warning and ollama appears as reachable in the model catalog
• Manual: send a chat message to an ollama-backed agent end-to-end