fix(storage): pin Redis client to RESP2 so FT.SEARCH decodes correctly

[gzileni]

Problem

Every /query call against a freshly-ingested index returned zero sources even when keyword and vector matches existed in the underlying Redis Stack. redis-cli FT.SEARCH … from the host returned the expected docs; the Python path through RedisVectorStore returned 0.

Root cause

Redis Stack 7.2+ negotiates RESP3 by default. On RESP3 the FT.SEARCH reply is a dict:

```python
{b'total_results': N, b'results': [...], b'attributes': [...], ...}
```

The ft().search() helper in redis-py still parses the legacy RESP2 positional list shape ([count, doc_id, doc_data, ...]). Faced with a dict it silently produces total=0, docs=[] — looks like "no matches" instead of a decode failure.

Fix

Pass protocol=2 to aioredis.from_url in RedisVectorStore.__init__. Forces the connection to RESP2 so the server replies with the positional list the helper expects. One-line change.

Verified end-to-end (against a 32-chunk ingested namespace)

Before:
```
Q='mps' -> sources=0
Q='FTSE MIB' -> sources=0
Q='borsa italiana' -> sources=0
```

After:
```
Q='mps' -> sources=5
Q='FTSE MIB' -> sources=7
Q='borsa italiana' -> sources=6
```

Same data, same Redis, same query, only difference is the protocol flag.

Test plan

• Live verification: rebuild kg-api, run a chat that previously failed → now returns grounded answers with cited sources.
• Add an integration test that ingests one doc and asserts at least one keyword + one vector hit (deferred — kg-api currently has no integration test harness against a live Redis).

🤖 Generated with Claude Code