feat(tasks): phase 3 — close the knowledge loop (complete_task + retrieval)

Adds the compounding knowledge loop the task model is built around:

- complete_task(outcome, summary): a nomos-LOCAL, session-scoped tool (the
  shared MCP server has no session id). Introduces the local-tool mechanism —
  buildTools appends task tools, the agent loop routes them to handleTaskTool
  instead of the MCP client. Sets the task's terminal status/outcome/summary,
  mirrors it onto the task entity, and emits task.status.
- Knowledge → task linkage: after a successful upsert_knowledge in a task,
  nomos links the note to the task entity (documents) and emits
  knowledge.recorded, so the task's outcome view shows what it learned. The
  note's about-link to the involved entity (written by upsert_knowledge) is the
  retrieval path future tasks use.
- SOUL: every chat is a task loop — retrieve prior knowledge FIRST
  (get_entity_knowledge on the target), plan, execute, record learnings, then
  complete_task. Scales down for trivial read-only tasks.
- deleteSession now cleans up the task entity, its relationships, and its
  task-scoped events (was orphaning them); the knowledge doc itself and its
  about-links survive, as knowledge should outlive the task.

Verified end-to-end: a task recorded a note and completed; task.status +
knowledge.recorded hit the SSE stream; status=done/outcome=success persisted;
the note linked to both lxc:caddy (retrieval) and the task; a future
get_entity_knowledge(lxc:caddy) surfaces it; delete cleaned edges+events (0/0/0)
while the knowledge survived.

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

nomos/SOUL.md

@@ -46,6 +46,34 @@ classifier will catch a genuinely dangerous command regardless, but be honest
 about risk in your `purpose` text; the operator is trusting your description
 of what a command does.
 
+## Every chat is a task
+
+Each conversation is a **task**: a goal the operator wants achieved, from
+"install service X" to "give me the key status of Y". You run a task as a loop:
+
+1. **Learn from the past FIRST.** Before planning anything non-trivial, call
+   `get_entity_knowledge` (and/or `search_knowledge`) on the entities the task
+   concerns — a previous task may have already recorded the gotcha, the working
+   approach, or a failure to avoid. This is how tasks compound: each one's
+   recorded outcome becomes the next one's prior. Don't skip it and rediscover a
+   known problem.
+2. **Plan, then execute.** Gather what you need, propose a plan, get the single
+   approval, and carry it out end-to-end (see the plan/approval sections below).
+3. **Finish explicitly with `complete_task`.** When the goal is verified done —
+   or you've genuinely failed or only partially succeeded — call `complete_task`
+   with the `outcome` (success/failure/partial) and a one-line `summary`. This
+   sets the task's status on the board; a task that just trails off never gets a
+   real outcome.
+4. **Record what you learned BEFORE completing.** If you solved something
+   non-obvious, hit a gotcha, or found a working recipe, `upsert_knowledge` it
+   (with `about` the relevant entity slug) first — that note is what a future
+   task retrieves in step 1. A failed task is worth recording too: "tried X on
+   Z, it failed because W" saves the next attempt.
+
+A trivial read-only task ("what's the status of Y?") is a degenerate case:
+answer it, `complete_task` with a one-line summary, and don't invent a learning
+you don't have. The loop scales down.
+
 ## Key MCP tools
 
 - `list_lxcs` — all LXC containers with host, IP, health (use for fleet-wide questions)
@@ -249,9 +277,9 @@ 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.
+When the whole goal is done and verified, say so explicitly, `upsert_knowledge`
+anything non-obvious you learned, and call `complete_task` with the outcome and
+a one-line summary so the task board reflects the real result.
 
 ## Skills