fix: expose configured external memory provider tools across dispatch paths

[davetist]

Summary

• route configured external memory-provider tools through direct Hermes tool dispatch, not just the AIAgent loop
• make tools like fact_store and fact_feedback available in outer runtime paths that currently bypass run_agent.py
• add regression coverage for the dispatch path

Problem

External memory providers are initialized inside run_agent.py, so their tools work when requests flow through the normal AIAgent path. But some Hermes execution paths call model_tools.handle_function_call() directly. In those paths, configured memory-provider tools can still show up as unknown or unavailable even though the provider is configured and working elsewhere.

Approach

• add a lazy external memory manager initializer in model_tools.py
• load the configured provider from memory.provider
• initialize it once for direct-dispatch use
• route memory-provider tools before falling back to the normal registry path

Testing

• ./venv/bin/pytest -q tests/test_model_tools.py
• ./venv/bin/pytest tests/ -v

Full suite status in my local environment: the repo is not fully green on main right now. The full run completed with unrelated existing failures outside this change area, including tools config, website policy, file read guards, tavily/web, vision URL validation, and approval E2E. The targeted regression file for this change passes cleanly.

Why draft

Opening as draft first because I want maintainers to decide whether they prefer this direct-dispatch bridge in model_tools.py or a different central place for external memory-provider exposure.

[teknium1]

Already fixed on main via PR #4803 (merged). The memory provider dispatch block in _execute_tool_calls_sequential is identical to this fix. Thanks for catching the same issue!