feat(memory): structured knowledge graph (tier 4, optional)

**Context:** ROADMAP.md → Memory security → Structured knowledge graph (tier 4)

---

## Component

Agent (Python runtime)

## Describe the feature

Optional **long-term** direction: structured knowledge graph if semantic + episodic AgentCore Memory proves insufficient for repo-specific query patterns (e.g. cross-file API dependency queries).

## Use case

Some repos need relationship-aware retrieval ("what calls this endpoint?") beyond vector similarity. Defer until semantic/episodic limits are measured in production.

## Proposed solution

1. RFC spike: graph schema, query API, sync from codebase indexing.
2. Integration point with hydration budget.
3. Explicitly **optional**—ship only if evaluation pipeline shows retrieval gaps.
4. May leverage external store (Neptune, or embedded graph) — TBD in RFC.

## Other information

- Lowest priority in memory epic; do not block other memory security work.
- Design context: `docs/design/MEMORY.md`.

- [ ] This might be a breaking change

ROADMAP.md と docs/design/MEMORY.md を読み、メモリセキュリティのコンテキストと既存の意味的およびエピソード的な制限を理解してください。提案された RFC スパイクから始め、グラフスキーマ、クエリ API、コードベースインデックスの同期、hydration-budget の統合を文書化してください。評価パイプラインがオプション機能を正当化し、RFC が外部ストアの選択を解決すれば完了です。

索引モデルが issue の本文から書いたものです。