feat(mcp): add mem_relate tool for observation relations

[Alejandro-M-P]

Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

Problem Description

The memory_relations table already exists in the schema (with sync_id, source_id, target_id, relation, etc.) and Go methods exist in internal/store/relations.go. However, there is no MCP tool to create links between related observations. AI agents cannot programmatically relate observations.

Proposed Solution

Create mem_relate MCP tool that wires the existing Go methods. The tool should accept:

• source_sync_id: sync_id of the source observation
• target_sync_id: sync_id of the target observation
• relation: type of relation (e.g., "supersedes", "related", "conflicts_with")
• reason: optional reason for the relation

The tool should call existing methods like SaveRelation() from internal/store/relations.go.

Affected Area

Other (MCP Server)

Alternatives Considered

None - the infrastructure (table + Go methods) already exists, only the MCP tool is missing. This is a wiring task, not a new feature.

[Alan-TheGentleman]

Good idea, but this touches relation semantics and conflict-judging behavior. Before a PR makes sense, we need the intended contract for authorization, idempotency, and allowed relation types. Please propose that design here first.

[Alejandro-M-P]

1. Authorization Contract

• Who: Any agent with MCP access (OpenCode, Claude, etc.)
• Project-scoping (enforced): Relations ONLY between observations in the same project. If source.project != target.project → error.
• Provenance: marked_by_actor, marked_by_kind="agent", session_id are captured.

2. Idempotency Policy

Upsert semantics:

• Same (source_id, target_id, relation) → return existing relation (no-op)
• Different relation on same pair → overwrite (deliberate revision, matches mem_judge re-judge policy)
• No existing row → INSERT
  Need new store method: GetRelationBySourceTarget().

3. Allowed Relation Types

Final verdict verbs ONLY (NOT pending):

• related, compatible, scoped, conflicts_with, supersedes, not_conflict
pending is reserved for the FindCandidates auto-detection flow.

---

Key distinction from mem_judge:

• mem_judge → reactive flow (pending candidates → judged)
• mem_relate → proactive flow (agent-driven, direct to judged)

[ricardoarz-dev]

+1 con caso operacional.

Setup multi-agente, varios proyectos. Hoy cuando un agente busca un tema en mem_search, recibe matches directos pero sin awareness de que esas observaciones están vinculadas con otras vía relaciones. Termina haciendo 3-4 búsquedas separadas para reconstruir contexto.

La table memory_relations ya está en el schema — este wiring es el último cable. Su impacto operacional es grande para flujos multi-agente: cada agente arranca con contexto coherente en una sola llamada, no fragmentado.

Si ayuda priorizarlo, cuento como caso de uso real en producción.