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/api.go

@@ -132,13 +132,13 @@ func New(cfg *config.Config, svc *service.Service) *gin.Engine {
 	// The garden assistant. Its routes are registered UNCONDITIONALLY and the live
 	// Runner sits behind an atomic pointer in the holder, so a settings change can
 	// turn the assistant on or off at runtime (#79). Each handler nil-checks
-	// agent.get(); a request while the assistant is off gets a clean 404/"not
-	// available", not a panic and not a missing route.
+	// agent.get(); a chat request while the assistant is off gets a clean 503
+	// (AGENT_DISABLED), not a panic and not a missing route.
 	//
 	// The holder resolves its initial Runner from settings + environment at
 	// construction. If the key never reaches the container, the assistant is off
 	// and the reason is logged below — the same operability need #72 added.
-	h.agent = newAgentHolder(context.Background(), svc, cfg.Agent.OllamaCloudAPIKey)
+	h.agent = newAgentHolder(context.Background(), svc)
 	if cfg.Agent.OllamaCloudAPIKey == "" {
 		slog.Info("api: garden assistant has no API key",
 			"hint", "set OLLAMA_CLOUD_API_KEY in the container's environment (not just the stack's); the model can be chosen in Settings")