Say at startup why the assistant is off

Verifying the live deploy, the agent routes stayed 404 while every other route
from the same build answered — so the binary was current and Agent.Ready() was
simply false. Working out which of the three conditions failed meant reading the
source, because pansy logged the enabled case and said nothing at all about the
disabled one.

It now logs which condition failed, with the hint that actually matters: an
orchestrator's stack-level environment is not the container's environment, and
a key set in one but not passed through to the other looks exactly like a key
that was never set. README says the same thing next to the compose example.

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

internal/api/api.go

@@ -131,6 +131,17 @@ func New(cfg *config.Config, svc *service.Service) *gin.Engine {
 	// The garden assistant, registered only when it can actually be offered —
 	// the same shape as OIDC. An instance with no API key serves the app
 	// normally and simply doesn't have these routes.
+	if !cfg.Agent.Ready() {
+		// Say WHY, at startup, in the logs an operator is already looking at.
+		// Someone who set the key and sees no assistant otherwise has nothing to
+		// check — and "is the variable reaching the container?" is exactly the
+		// question they need answered.
+		slog.Info("api: garden assistant disabled",
+			"enabled", cfg.Agent.Enabled,
+			"hasApiKey", cfg.Agent.OllamaCloudAPIKey != "",
+			"model", cfg.Agent.Model,
+			"hint", "needs OLLAMA_CLOUD_API_KEY set in the container's environment (not just the stack's)")
+	}
 	if cfg.Agent.Ready() {
 		runner, err := agent.NewRunner(svc, cfg)
 		if err != nil {