Address Gadfly findings on #90 (blocking round)

- Remove config.AgentConfig.Ready() — dead after the refactor (no non-test
  callers), and its doc comment ("route registration and capabilities gate on
  this") was now false. EffectiveAgent.Ready() carries the same logic and IS
  used, see below.
- agentHolder now uses eff.Ready() and eff.APIKey instead of an inline check and
  a redundant apiKey field it held separately. This makes EffectiveAgent.APIKey/
  Ready() production-used rather than test-only, drops the duplicated readiness
  check, and simplifies newAgentHolder's signature.
- settingsPayload no longer swallows an EffectiveAgent error into a misleading
  empty "effective" view (which would read as "nothing configured"). It returns
  the error; the handlers surface it as a 500. EffectiveAgent re-reads the row
  GetInstanceSettings just returned, so a failure there is a real DB fault.
- Frontend streamChat handles 503 (assistant disabled at runtime) distinctly
  from 404 (endpoint absent) — the backend returns 503 AGENT_DISABLED now, which
  the old code mislabelled.
- Fixed the api.go comment that still said a disabled request gets a 404 — it's
  a 503.
- updateSettings uses the shared parseNullable[bool] instead of a bespoke
  parseNullableBool (now removed).
- NewRunner drops its empty-spec guard; agentmodel.Resolve already owns that
  check, so one place decides what a valid spec is.
- rebuild-on-resolve-error now documents WHY it keeps the current Runner rather
  than tearing down a working assistant on a transient DB blip: the state is
  persisted, the next rebuild reconciles, and killing a live assistant on a read
  hiccup is worse than a brief stale window.

Not changed: the store's version-conflict fallback returning GetInstanceSettings'
error instead of ErrVersionConflict when that read also fails. That's the exact
pattern every other version-guarded update uses (gardens/objects/plants); making
only this one differ would be the inconsistency. A DB read failing immediately
after the guarded UPDATE on the same local SQLite file is a disk-fault edge case,
and surfacing that error is defensible.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ

internal/api/agent_holder.go

@@ -24,10 +24,6 @@ import (
 // than assuming a Runner is present.
 type agentHolder struct {
 	svc *service.Service
-	// apiKey is the OLLAMA_CLOUD_API_KEY from the environment. It never changes at
-	// runtime — only the model spec and the enabled flag are settings — and it is
-	// deliberately not something the settings UI can read or write.
-	apiKey string
 
 	ptr atomic.Pointer[agent.Runner]
 	// rebuildMu serializes rebuilds so two concurrent settings saves can't
@@ -39,8 +35,8 @@ type agentHolder struct {
 // newAgentHolder builds the holder and resolves the initial Runner from whatever
 // the settings + environment currently say. A resolution failure is logged and
 // left as "no assistant", never fatal: a garden planner must still boot.
-func newAgentHolder(ctx context.Context, svc *service.Service, apiKey string) *agentHolder {
-	h := &agentHolder{svc: svc, apiKey: apiKey}
+func newAgentHolder(ctx context.Context, svc *service.Service) *agentHolder {
+	h := &agentHolder{svc: svc}
 	h.rebuild(ctx)
 	return h
 }
@@ -63,18 +59,23 @@ func (h *agentHolder) rebuild(ctx context.Context) {
 
 	eff, err := h.svc.EffectiveAgent(ctx)
 	if err != nil {
-		slog.Error("api: could not resolve agent settings; leaving assistant unchanged", "error", err)
+		// EffectiveAgent errors only if the settings row can't be read — a DB fault,
+		// and a very transient one when it happens right after a settings write. We
+		// keep the current Runner rather than tear down a working assistant on a
+		// blip: the state is already persisted, so the next rebuild (any later save,
+		// or a restart) reconciles it. Loud, because a persistent failure here means
+		// the live assistant no longer matches stored settings.
+		slog.Error("api: could not resolve agent settings; leaving the assistant as-is", "error", err)
 		return
 	}
-	// The env key is authoritative; EffectiveAgent reports it, but the holder was
-	// handed it directly at construction, so use that.
-	if !eff.Enabled || h.apiKey == "" || eff.Model == "" {
+	if !eff.Ready() {
 		if h.ptr.Swap(nil) != nil {
-			slog.Info("api: garden assistant turned off", "enabled", eff.Enabled, "hasModel", eff.Model != "")
+			slog.Info("api: garden assistant turned off",
+				"enabled", eff.Enabled, "hasKey", eff.APIKey != "", "hasModel", eff.Model != "")
 		}
 		return
 	}
-	runner, err := agent.NewRunner(h.svc, h.apiKey, eff.Model)
+	runner, err := agent.NewRunner(h.svc, eff.APIKey, eff.Model)
 	if err != nil {
 		// Configured but unusable. Turn the assistant off rather than leaving a
 		// stale Runner on the old model — an admin who just pointed it at a broken