feat(tasks): make research-first / knowledge-write-back-last explicit steps

Closes the gap that made the knowledge loop optional/implicit: every
non-trivial task now has an EXPLICIT first plan step (research) and last
plan step (write back), not just background behavior the model might skip.

New MCP tools (the agent had no way to do these before — only REST endpoints
existed, unexposed to it):
- update_entity_attributes(slug, attributes): shallow-merge new/changed facts
  into an entity (an IP, a version, a discovered port) so a future task
  doesn't have to rediscover them from scratch. No approval required — this
  updates the knowledge graph, not live infra.
- create_relationship(source, target, type): record a discovered edge
  (depends-on, hosts, provides, ...). Idempotent, FK-validated against the
  ontology's relationship_types, no approval required.

SOUL.md: restructured the task loop so step 1 is explicitly "gather
knowledge, not just status" (get_entity_knowledge, search_knowledge,
get_relations, get_blast_radius, http_get) and the last step before
complete_task is explicitly "write back" (update_entity_attributes,
create_relationship, upsert_knowledge) — both called out as real plan
entries the operator should see in propose_plan, not silent side-work. This
is what prevents the graph drifting from reality and is the concrete
mechanism behind "tasks compound."

propose_plan's tool description reinforces the same first-step/last-step
convention at the call site.

Verified against the live stack: both tools registered and callable via MCP;
update_entity_attributes merged an attribute correctly; create_relationship
rejected an invalid type (FK violation, clear error) and succeeded with a
valid type+direction, confirmed idempotent (2 calls, 1 row).

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

cmd/nomos/tasks.go

@@ -37,6 +37,11 @@ func taskToolDefs() []toolDef {
 				"call, listing every step end-to-end — not just the next one. The operator " +
 				"sees the full list in the context panel and watches it progress; a plan " +
 				"with only 1 step looks broken to them even if you intend to add more later. " +
+				"Your FIRST step should be research (prior knowledge, relations, blast radius " +
+				"— not just this target's status) and your LAST step should be writing back " +
+				"what you learned (update_entity_attributes / create_relationship / " +
+				"upsert_knowledge) BEFORE complete_task — this is what keeps the knowledge " +
+				"graph from drifting out of date. " +
 				"Call this ONCE, before you start executing (after gathering what you need). " +
 				"As you work, call update_plan_step (not propose_plan again) to advance each " +
 				"step. Only re-call propose_plan if the plan itself has fundamentally changed " +