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

Read ROADMAP.md and docs/design/MEMORY.md to understand the memory-security context and existing semantic and episodic limits. Begin with the proposed RFC spike, documenting the graph schema, query API, codebase-index synchronization, and hydration-budget integration. Done means the evaluation pipeline justifies the optional feature and the RFC resolves the external-store choice.

Written by the indexing model from the issue text.