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>

web/src/lib/stores/chat.ts

@@ -137,8 +137,13 @@ function startPolling(sessionId: string) {
     if (pollingSessionId !== sessionId || get(currentSession) !== sessionId) return
     const msgs = await fetchMessages(sessionId)
     if (get(streaming) || pollingSessionId !== sessionId) return // re-check: the fetch itself takes time
-    const current = get(messages)
-    if (msgs.length === current.length) return
+    // No cheap "anything new?" check: the auto-continuation worker updates a
+    // placeholder message IN PLACE as each tool call lands (see
+    // cmd/nomos/continue.go), so the message COUNT stays the same while the
+    // content changes — a length-only diff (the previous version of this
+    // code) never detected those updates and progress looked frozen even
+    // though the backend was actively working. Just re-set every tick;
+    // Svelte's own diffing keeps the actual re-render cheap.
     sessionMessages.set(msgs)
     messages.set(toChatMessages(msgs))
   }, 3000)