[Feature Request]: Support Graph RAG capabilities: graph storage + multi-hop traversal + hybrid vector-graph search

## 🌟 Summary

To enable **Graph RAG** (Graph-based Retrieval-Augmented Generation) scenarios, Infinity should support a minimal but powerful set of graph database features. This request covers **P0 (must-have)** and **P1 (core)** functionalities, focusing on **entity-relationship storage**, **neighbor/meta-path queries**, and **hybrid vector-graph retrieval**.

> **Goal**: Not to become a full graph database, but to enable "graph-aware vector search" — retrieving semantically relevant entities along with their structural neighbors for richer RAG context.

---

## 📦 Scope Breakdown

### ✅ P0 – Must Have (Storage + Basic Graph Traversal)

| Feature | Description |
|---------|-------------|
| **Entity table** | Store entities with ID, name, type, properties (JSON), and optional vector embedding |
| **Relation table** | Store directed/undirected edges with `from_entity`, `to_entity`, `relation_type`, `weight`, properties |
| **1-hop neighbor query** | Retrieve all direct neighbors (inbound + outbound) of a given entity |
| **2-hop neighbor query** | Retrieve nodes within 2 steps from a starting entity |

### ✅ P1 – Core (Advanced Graph + Hybrid Search)

| Feature | Description |
|---------|-------------|
| **Meta-path query** | Filter paths by relationship types (e.g., `person -[works_for]-> company -[produces]-> product`) |
| **Hybrid search: vector + graph expansion** | First retrieve top-K entities by vector similarity, then expand each to N-hop neighbors, merge/rerank results |
| **Community/Cluster query** | Store precomputed `community_id` on entities; retrieve all entities in the same community |

## 🧱 Proposed SQL Syntax (Extension)

### 1. Storage Schema

```sql
-- Entity table
CREATE TABLE entities (
entity_id VARCHAR PRIMARY KEY,
name TEXT,
type VARCHAR,
properties JSON,
embedding VECTOR, -- optional, for vector search
community_id VARCHAR -- for community queries
);

-- Relation table
CREATE TABLE relations (
relation_id VARCHAR PRIMARY KEY,
from_entity VARCHAR REFERENCES entities(entity_id),
to_entity VARCHAR REFERENCES entities(entity_id),
relation_type VARCHAR,
weight FLOAT DEFAULT 1.0,
properties JSON
);
```

### Graph Traversal (P0)
```sql
-- 1-hop neighbors
GRAPH MATCH (e1)-[r]->(e2)
WHERE e1.entity_id = 'E123'
RETURN e2.entity_id, e2.name, r.relation_type, r.weight;

-- 2-hop neighbors
GRAPH MATCH (e1)-[r1]-(e2)-[r2]-(e3)
WHERE e1.entity_id = 'E123'
RETURN e3.entity_id, e3.name,
[r1.relation_type, r2.relation_type] AS path_types;
```
### 3. Meta-path Query (P1)
```sql
-- Person → Company → Product
GRAPH MATCH (p:person)-[r1:works_for]->(c:company)-[r2:produces]->(prod:product)
WHERE p.entity_id = 'P001'
RETURN prod.name, prod.properties;
```

### 4. Hybrid Vector + Graph Search (P1)

```sql
WITH similar AS (
SELECT entity_id FROM entities
WHERE embedding MATCH 'query vector' LIMIT 5
)
GRAPH MATCH (e)-[r*1..2]-(neighbor)
WHERE e.entity_id IN (SELECT entity_id FROM similar)
RETURN e.entity_id, neighbor.entity_id, r.relation_type;
```

### 5. Community Query (P1)

```sql
SELECT entity_id, name FROM entities
WHERE community_id = (
SELECT community_id FROM entities WHERE entity_id = 'E123'
);
```

No source files, tests, or entry points are identified. Start by reviewing the proposed entity and relation schemas, GRAPH MATCH syntax, and hybrid vector-plus-graph query flow; done means delivering an agreed scope covering P0 storage and traversal plus the selected P1 capabilities.

Written by the indexing model from the issue text.