graphify: vector/embedding search on top of the tropo storage layer

[Jeff-Kazzee]

The storage foundation landed in 0.2.0: LanceDB on disk, BM25 full-text search via tropo query, tiered backend config in .vivary/storage.toml. That's the substrate.

What's still needed — and what this issue tracks:

• Embedding generation — when a node is upserted to the embedded backend, also generate and store a vector (text-embedding-3-small or local equiv). Explicit opt-in via [storage.embedding] in storage.toml.
• Vector search in tropo query — --mode semantic flag; ANN over the stored embeddings. Falls back to BM25 if no embeddings present.
• Clustering / community detection — group nodes by embedding similarity and expose as a graph view layer. Lets an agent navigate by meaning, not just explicit links.

Architecture constraint: this layer CONSUMES tropo's typed graph. The deterministic graph stays the substrate; semantic search is an opt-in overlay. No LLM dependency in tropo's core; embedding calls are gated behind the [embedded] extra and [storage.embedding] config.

Depends on: 0.2.0 storage layer (done), a real embedding provider integration (0.3.x scope).

[Jeff-Kazzee]

Related next memory-architecture spike: #84 evaluates whether Cognee-style graph recall should be an optional Vivary provider or just an architecture pattern. Keep this aligned so #20 remains graph-shaped typed-node retrieval, not a separate naive RAG track.

[Jeff-Kazzee]

Narrowing this to stay aligned with the provider/capability model now being implemented.

Going forward, #20 should track typed-node semantic search over Vivary graph truth, not a separate naive chunked-RAG system. The current setup branch adds create-vivary capabilities, --memory local|cognee, .vivary/memory.toml, and doctor memory reporting; the semantic-memory provider work continues in #86. If tropo query --mode semantic lands later, it should return typed Vivary node ids/paths/types and share the same privacy-first provider contract.