fix: mem0 semantic retrieval returned 0 results, plus robust MCP server path

[zJok3R]

Summary

Two independent kernel fixes, both exercised locally against a real mem0 + Ollama setup.

1. mem0 semantic retrieval returned 0 results (e79b9c6)

add/get reported success but semantic retrieval returned nothing. Two root causes:

• Silent no-op on add. mem0 2.0.6 defaults to infer=True, running LLM fact-extraction over the content. With small/local models (e.g. qwen2.5:7b) this often yields {"results": []} and stores nothing, while add_memory still reports success via a fallback id. We already pass fully-formed MemoryNotes, so we now pass infer=False to persist them verbatim.
• Sharing-filter asymmetry. Retrieval injects agent_name and the cross-agent sharing filter matches owner_agent against it, but add never set owner_agent — so an agent could not find its own memories. We now setdefault owner_agent to the requesting agent on add (explicit values from ConversationExtractor are preserved). Applies to all providers via the shared _apply_sharing_filter.
• Adds the ollama package to requirements — mem0's Ollama backend imports it lazily and otherwise prompts for an interactive install (fails non-interactively).

Per the memory provider test suite (test_mem0_provider.py): 8/10 → 12/12.

2. Robust MCP server script path resolution (6b63d85)

• get_mcp_server_script_path() now defaults to the in-repo aios/tool/mcp_server.py when unset, and handles absolute paths (previously it crashed on a None config and always prefixed os.getcwd()).
• Launch the MCP server via sys.executable instead of a hardcoded "python".
• Guard against a missing script path before os.path.exists.
• Document tool.mcp_server_script_path in config.yaml.example.

Testing

• test_mem0_provider.py: 8/10 → 12/12 for the memory fix.
• pre-commit (ruff, trailing-whitespace, end-of-file, check-yaml) clean on all touched files.