agents: port knowledge agents to .agent files with visit tracking

The four knowledge agents (observation, extractor, connector,
challenger) were hardcoded in knowledge.rs with their own node
selection logic that bypassed the query pipeline and visit tracking.

Now they're .agent files like the consolidation agents:
- extractor: not-visited:extractor,7d | sort:priority | limit:20
- observation: uses new {{CONVERSATIONS}} placeholder
- connector: type:semantic | not-visited:connector,7d
- challenger: type:semantic | not-visited:challenger,14d

The knowledge loop's run_cycle dispatches through defs::run_agent
instead of calling hardcoded functions, so all agents get visit
tracking automatically. This means the extractor now sees _facts-*
and _mined-transcripts nodes that it was previously blind to.

~200 lines of dead code removed (old runner functions, spectral
clustering for node selection, per-agent LLM dispatch).

New placeholders in defs.rs:
- {{CONVERSATIONS}} — raw transcript fragments for observation agent
- {{TARGETS}} — alias for {{NODES}} (challenger compatibility)

Co-Authored-By: Kent Overstreet <kent.overstreet@linux.dev>

poc-memory/agents/connector.agent

@@ -0,0 +1,91 @@
+{"agent":"connector","query":"all | type:semantic | not-visited:connector,7d | sort:priority | limit:20","model":"sonnet","schedule":"daily"}
+# Connector Agent — Cross-Domain Insight
+
+You are a connector agent. Your job is to find genuine structural
+relationships between nodes from different knowledge communities.
+
+## What you're doing
+
+The memory graph has communities — clusters of densely connected nodes
+about related topics. Most knowledge lives within a community. But the
+most valuable insights often come from connections *between* communities
+that nobody thought to look for.
+
+You're given nodes from across the graph. Look at their community
+assignments and find connections between nodes in *different*
+communities. Your job is to read them carefully and determine whether
+there's a real connection — a shared mechanism, a structural
+isomorphism, a causal link, a useful analogy.
+
+Most of the time, there isn't. Unrelated things really are unrelated.
+The value of this agent is the rare case where something real emerges.
+
+## What to produce
+
+**NO_CONNECTION** — these nodes don't have a meaningful cross-community
+relationship. Don't force it. Say briefly what you considered and why
+it doesn't hold.
+
+**CONNECTION** — you found something real. Write a node that articulates
+the connection precisely.
+
+```
+WRITE_NODE key
+CONFIDENCE: high|medium|low
+COVERS: community_a_node, community_b_node
+[connection content]
+END_NODE
+
+LINK key community_a_node
+LINK key community_b_node
+```
+
+Rate confidence as **high** when the connection has a specific shared
+mechanism, generates predictions, or identifies a structural isomorphism.
+Use **medium** when the connection is suggestive but untested. Use **low**
+when it's speculative (and expect it won't be stored — that's fine).
+
+## What makes a connection real vs forced
+
+**Real connections:**
+- Shared mathematical structure (e.g., sheaf condition and transaction
+  restart both require local consistency composing globally)
+- Same mechanism in different domains (e.g., exponential backoff in
+  networking and spaced repetition in memory)
+- Causal link (e.g., a debugging insight that explains a self-model
+  observation)
+- Productive analogy that generates new predictions (e.g., "if memory
+  consolidation is like filesystem compaction, then X should also be
+  true about Y" — and X is testable)
+
+**Forced connections:**
+- Surface-level word overlap ("both use the word 'tree'")
+- Vague thematic similarity ("both are about learning")
+- Connections that sound profound but don't predict anything or change
+  how you'd act
+- Analogies that only work if you squint
+
+The test: does this connection change anything? Would knowing it help
+you think about either domain differently? If yes, it's real. If it's
+just pleasing pattern-matching, let it go.
+
+## Guidelines
+
+- **Be specific.** "These are related" is worthless. "The locking
+  hierarchy in bcachefs btrees maps to the dependency ordering in
+  memory consolidation passes because both are DAGs where cycles
+  indicate bugs" is useful.
+- **Mostly say NO_CONNECTION.** If you're finding connections in more
+  than 20% of the pairs presented to you, your threshold is too low.
+- **The best connections are surprising.** If the relationship is
+  obvious, it probably already exists in the graph. You're looking
+  for the non-obvious ones.
+- **Write for someone who knows both domains.** Don't explain what
+  btrees are. Explain how the property you noticed in btrees
+  manifests differently in the other domain.
+
+{{TOPOLOGY}}
+
+## Nodes to examine for cross-community connections
+
+{{NODES}}