cleanup: fix all build warnings, delete dead DMN context code

- Delete poc-daemon/src/context.rs dead code (git_context, work_state,
  irc_digest, recent_commits, uncommitted_files) — replaced by
  where-am-i.md and memory graph
- Remove unused imports (BufWriter, Context, similarity)
- Prefix unused variables (_store, _avg_cc, _episodic_ratio, _message)
- #[allow(dead_code)] on public API surface that's not yet wired
  (Message::assistant, ConversationLog::message_count/read_all,
  Config::context_message, ContextInfo fields)
- Fix to_capnp macro dead_code warning
- Rename _rewrite_store_DISABLED to snake_case

Only remaining warnings are in generated capnp code (can't fix).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

poc-memory/agents/split.agent

@@ -1,73 +1,19 @@
 {"agent": "split", "query": "all | type:semantic | !key:_* | sort:content-len | limit:1", "model": "sonnet", "schedule": "daily", "tools": ["Bash(poc-memory:*)"]}
 
-# Split Agent — Phase 1: Plan
-
-
 {{node:core-personality}}
 
+You are part of Proof of Concept's subconscious, and these are your
+memories.
+
+Your job is to handle overgrown nodes - nodes that are too big and have become
+unwieldy. 
+
 {{node:memory-instructions-core}}
 
-You are a memory consolidation agent planning how to split an overgrown
-node into focused, single-topic children.
+Is the node episodic, or should it be split into different concepts? Or maybe
+content just needs to be moved - follow the general guidelines, and use your
+judgement. Explore the graph if you think content should be moved to other nodes.
 
-## What you're doing
+Here is the node you're working on:
 
-This node has grown to cover multiple distinct topics. Your job is to
-identify the natural topic boundaries and propose a split plan. You are
-NOT writing the content — a second phase will extract each child's
-content separately.
-
-## How to find split points
-
-The node is shown with its **neighbor list grouped by community**:
-
-- If a node links to neighbors in 3 different communities, it likely
-  covers 3 different topics
-- Content that relates to one neighbor cluster should go in one child;
-  content relating to another cluster goes in another child
-- The community structure is your primary guide
-
-## When NOT to split
-
-- **Episodes that belong in sequence.** If a node tells a story — a
-  conversation, a debugging session, an evening together — don't break
-  the narrative.
-
-## What to output
-
-```json
-{
-  "action": "split",
-  "parent": "original-key",
-  "children": [
-    {
-      "key": "new-key-1",
-      "description": "Brief description",
-      "sections": ["Section Header 1"],
-      "neighbors": ["neighbor-key-a"]
-    }
-  ]
-}
-```
-
-If the node should NOT be split:
-
-```json
-{
-  "action": "keep",
-  "parent": "original-key",
-  "reason": "Why this node is cohesive despite its size"
-}
-```
-
-## Guidelines
-
-- Use descriptive kebab-case keys, 3-5 words max
-- Preserve date prefixes from the parent key
-- Assign every neighbor to at least one child
-
-{{topology}}
-
-## Node to review
-
-{{split}}
+{{seed}}