feat(llama-index): get_triplets() schema-lookup fallback when relation_names omitted #19

Problem

CoordinodePropertyGraphStore.get_triplets() raises NotImplementedError when called without relation_names:

# Raises NotImplementedError
store.get_triplets(entity_names=["Alice"])

# Works
store.get_triplets(entity_names=["Alice"], relation_names=["KNOWS"])

This breaks LlamaIndex pipelines that call get_triplets() without explicit relation types — which is the default behavior in PropertyGraphIndex.

Root cause

CoordiNode Cypher does not support wildcard [r] relationship patterns (returns 0 rows). The current implementation raises NotImplementedError rather than falling back to a working approach.

Solution

Apply the same schema-lookup fallback already used in get_rel_map():

1. Call self._client.get_schema_text() to fetch the current schema
2. Parse edge types via _parse_edge_types_from_schema()
3. Build a typed pattern [r:TYPE_A|TYPE_B|...] from discovered types
4. Execute the query with the dynamic relation filter

This is a pure SDK fix — no DB changes required. The pattern is already proven in get_rel_map() in the same file.

Acceptance criteria

• get_triplets(entity_names=["Alice"]) returns results when schema has edge types
• get_triplets() with no args returns all triplets (up to limit)
• get_triplets(relation_names=["KNOWS"]) still works as before
• Unit test covering the schema-lookup fallback path
• Docstring updated (remove "relation_names is required" note)

No DB gate

This fix does not require any CoordiNode DB update. Can be implemented and released immediately.

Ref: CoordiNode Cypher gap G069 (wildcard [r] returns 0 rows — tracked separately in DB repo)