Admin-gated Settings: runtime model selection, enforce is_admin (#79)

Moves the agent model out of env-only config into an admin-editable Settings
section, and enforces is_admin for the first time — it has been in the schema
since migration 0001, plumbed to the client, and checked nowhere.

Backend:
- Migration 0010: instance_settings, a single-row (CHECK id=1) table — pansy's
  first instance-level state. Holds agent_model ('' = inherit env) and
  agent_enabled (NULL = inherit env), version-guarded like every mutable row.
  SECRETS STAY IN ENV: OLLAMA_CLOUD_API_KEY is never stored here.
- requireAdmin at the service seam (authoritative) plus a cheap middleware
  early-403. Non-admin gets 403, not 404 — settings existence isn't masked.
- EffectiveAgent resolves DB-over-env (model, enabled); key always from env.
- The live Runner is hot-swapped, not built once. agentHolder holds it behind
  an atomic.Pointer; the chat routes are now registered UNCONDITIONALLY and
  nil-check agent.get(), so a settings change turns the assistant on/off/onto a
  new model with no restart and no race against in-flight readers. /capabilities
  reads the pointer, so it reports what's live, not what booted.
- internal/agentmodel is a new leaf package holding the one place that knows how
  to turn a spec into a model. Both agent (to run) and service (to validate a
  spec before storing it) import it; it can't live in agent, which imports
  service. Settings PATCH validates the spec via Parse, so a typo is a 400 now
  rather than a broken assistant on the next turn.

Frontend:
- /settings route (admin guard), a Settings page (model field, tri-state
  enabled, live status), nav link shown only to admins.
- useCapabilities drops staleTime:Infinity — the assistant can now change under
  a running page — and the settings save invalidates it.

Contract change: chat routes always exist, so "assistant off" is a runtime 503
+ capabilities:false, not a missing route. Updated the test that asserted the
old shape.

Verified live against the built binary: disable flips capabilities to false and
logs it; re-enable with a new model swaps it back; a bad spec is rejected 400;
the setting persists across a restart. Swap is race-clean under `go test -race`.

Docs: README (precedence + key-stays-in-env), DESIGN (decision + routes),
CLAUDE (don't re-add conditional route registration; key never in the DB).

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

CLAUDE.md

@@ -163,6 +163,25 @@ Agent config: `OLLAMA_CLOUD_API_KEY`, `PANSY_AGENT_MODEL` (default
 strings pass verbatim to `majordomo.Parse`, so a comma-separated spec gives
 failover for free — don't parse that grammar in pansy.
 
+The model and enabled flag are also **admin-editable at runtime** in Settings
+(#79); the env vars are just defaults (precedence: DB setting → env → default).
+Two things this makes load-bearing:
+
+- **The live Runner is hot-swapped, not built once.** It sits behind an
+  `atomic.Pointer` in `internal/api` (`agentHolder`), and its routes are
+  registered *unconditionally* with a nil-check on `agent.get()`. Do NOT go back
+  to registering the chat routes only when a key is present — a settings change
+  has to be able to turn the assistant on without a restart, which a missing
+  route can't. `/capabilities` reads the pointer, so it reflects the live state.
+- **`OLLAMA_CLOUD_API_KEY` stays in the environment, never the DB.** Model
+  selection is a setting; the key is not. A secret in `instance_settings` lands
+  in every backup and in the undo history's blast radius. The Settings API
+  reports whether a key is *present*, never its value.
+- The "how to turn a spec into a model" knowledge lives once in
+  `internal/agentmodel`, imported by both `agent` (to run) and `service` (to
+  validate a spec before storing it). It can't live in `agent` — `agent` imports
+  `service`, so a `service`→`agent` import would cycle.
+
 `majordomo` is a **real dependency** now, resolved from the Gitea instance as a
 pseudo-version. There is no `replace` directive and there must not be one: a
 `replace` pointing at `../majordomo` builds on your laptop and breaks the Docker