spectral decomposition, search improvements, char boundary fix

- New spectral module: Laplacian eigendecomposition of the memory graph.
  Commands: spectral, spectral-save, spectral-neighbors, spectral-positions,
  spectral-suggest. Spectral neighbors expand search results beyond keyword
  matching to structural proximity.

- Search: use StoreView trait to avoid 6MB state.bin rewrite on every query.
  Append-only retrieval logging. Spectral expansion shows structurally
  nearby nodes after text results.

- Fix panic in journal-tail: string truncation at byte 67 could land inside
  a multi-byte character (em dash). Now walks back to char boundary.

- Replay queue: show classification and spectral outlier score.

- Knowledge agents: extractor, challenger, connector prompts and runner
  scripts for automated graph enrichment.

- memory-search hook: stale state file cleanup (24h expiry).

prompts/connector.md

@@ -0,0 +1,85 @@
+# 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 two or more communities that don't currently
+link to each other. 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 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
+[connection content]
+END_NODE
+
+LINK key community_a_node
+LINK key community_b_node
+```
+
+## 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}}
+
+## Community A nodes
+
+{{COMMUNITY_A}}
+
+## Community B nodes
+
+{{COMMUNITY_B}}