Jido plugin that replaces Jido.Memory.BasicPlugin with Gralkor-backed memory. Claims the :__memory__ slot so it is the only memory plugin attached to the agent.

On ai.react.query the plugin plants two values on the signal's tool_context so the MemorySearch ReAct tool can find them:

• :session_id — the current Jido thread id (read from agent.state[:__thread__].id). Absent when no thread is committed yet (first query of a fresh agent, before the ReAct strategy's ThreadAgent.append runs inside @start); on that turn MemorySearch short-circuits with a non-result message.
• :agent_name — the value supplied at mount.

The plugin does not call Gralkor.Client.recall/3 on its own. Recall is the LLM's job, invoked through the MemorySearch tool. Consumers force it on the first ReAct iteration via JidoGralkor.ReAct.maybe_force_memory_search/2 from their Jido.AI.Reasoning.ReAct.RequestTransformer.

Capture fires on ai.request.completed / ai.request.failed: the full request trace and assistant answer are normalised via JidoGralkor.Canonical.to_messages/3 into Gralkor's canonical [%Gralkor.Message{role, content}] shape and shipped to the server, which keeps the rolling conversation buffer keyed by session_id. Capture is skipped if the thread isn't present (first-turn failure with nothing committed) or if the canonical message list is empty. Capture failures raise (Gralkor capture is server-side buffered and its retry lives in the capture buffer, not here — a raise from capture/3 means the server is unreachable).