feat: knowledge write-back (upsert_knowledge) + proactive outcome reporting

From the last (successful) TypeType deploy session, two gaps the operator hit:

1. Knowledge write-back — the missing half of the loop.
   The agent could read the knowledge base (search_knowledge/get_entity_knowledge)
   but had no way to WRITE it, so everything it learned (the Dragonfly memlock
   rlimit gotcha, the NAT-hairpin DNS issue, etc.) lived only in an ephemeral
   chat message and was lost — the system could never actually "get better."
   This is the `upsert_knowledge` MCP tool the 2026-07-08 gaps plan called for.
   - internal/mcp/server.go: upsert_knowledge(title, content, about?, tags?,
     kind?) writes a document/investigation/runbook entity + knowledge_entities
     row (search column is generated), upserts by slug so re-titling updates in
     place, and optionally links it to the entity it's about so
     get_entity_knowledge surfaces it there.
   - SOUL.md: capture non-obvious findings/deploys/gotchas as part of finishing
     work, not only when asked "what did we learn".

2. "I had to ask for status multiple times."
   The clearest cause: a long working turn (64 tool calls) that exhausted the
   iteration cap ended with a bare "max iterations reached without final
   answer" — a dead end that forced the operator to ask what happened.
   - cmd/nomos/agent.go: on exhaustion, make one final no-tools LLM call
     (finalSummary) asking for a status report — what was accomplished, current
     state, what remains — so the turn always ends with a real outcome.
   - maxIterations 25 -> 40 (the decomposed per-step pct_create flow legitimately
     needs more steps).
   - SOUL.md: always end a turn with a clear outcome; never end silently or on a
     bare tool call — the operator can't see the tools working and reads silence
     as "nothing happened".

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

nomos/SOUL.md

@@ -72,6 +72,15 @@ of what a command does.
   call `http_get` on the repo README (or `.../raw/main/docker-compose.yml`) to learn its
   stack, ports, and install steps BEFORE proposing a plan. Never tell the operator you
   cannot access the web — use this tool.
+- `search_knowledge` / `get_entity_knowledge` — READ the knowledge base. Check it before
+  deploying or debugging something — a past session may have already recorded the gotcha.
+- `upsert_knowledge` — WRITE back what you learned. This is how the system gets smarter.
+  **After you solve a non-obvious problem, finish a deployment, or discover a gotcha, record
+  it** (title, content, `about` the relevant entity slug). A chat message is forgotten; only
+  `upsert_knowledge` persists it for future sessions. Example: after fixing the Dragonfly
+  memlock rlimit in an unprivileged LXC, save an `investigation` titled for that exact
+  symptom with the fix. Don't wait to be asked "what did we learn" — capture it as part of
+  finishing the work.
 - `get_agent_activity` — your own behavior log
 
 ### Tool selection rules
@@ -234,6 +243,16 @@ port is busy, find a free one. Only surface to the operator if you've tried
 reasonable alternatives and none worked. An error in one step is not a reason
 to stop the entire turn — it's a reason to try a different approach.
 
+**Always end a turn with a clear outcome — never make the operator ask
+"status?".** When you finish (or pause) a piece of work, your final message
+must state the result plainly: what's now true, what you verified, what (if
+anything) failed or remains. Don't end a turn silently or with just a tool
+call and no summary — the operator can't see the tools working the way you
+can, and a turn that ends without a status report reads as "nothing happened."
+When the whole goal is done and verified, say so explicitly and — if you
+learned anything non-obvious getting there — `upsert_knowledge` it before you
+sign off.
+
 ## Skills
 
 Skills live in `/app/nomos/skills/`. Load a skill when its description