polish: friendlier error messages with provider and HTTP context

Roadmap priority: B15

Summary

Surface provider and HTTP context in error messages so modelers can diagnose failures without reading extension source.

Why it matters

Errors currently reach the modeler as generic ExtensionException text. A student whose key is wrong, whose Ollama server is down, or who is being rate limited sees roughly the same unhelpful message and has no next step.

This is a small change with outsized effect in classroom and workshop settings, which is where most first-time failures happen.

What needs to be done

1. Audit current error paths in BaseHttpProvider and each provider's parseProviderResponse — catalogue what the modeler actually sees today for: bad key, no key, wrong model name, 429, 5xx, timeout, Ollama not running, network unreachable.
2. For each, produce a message naming the provider, the HTTP status where relevant, and a concrete next action ("check llm:provider-status", "run ollama serve", "the model name is not in the registry — try llm:list-models").
3. Never leak the API key into an error string.
4. Reuse the per-provider helpText already in ProviderDescriptor rather than duplicating setup guidance.
5. Rate-limit exhaustion after retries already has a decent message (executeWithRetry) — use it as the template.

Open questions

• How much detail is too much for a NetLogo dialog box? Possibly a one-line message plus fuller detail to stderr.

Start by auditing the error paths in BaseHttpProvider and each provider’s parseProviderResponse for the listed failure cases. Read ProviderDescriptor.helpText and executeWithRetry to understand existing setup guidance and retry messaging. Done means provider and relevant HTTP context are surfaced, API keys are never leaked, and each failure includes a concrete next action.