Fix

Reverses the priority in _load_config() so that load_config() (which has mtime-based cache invalidation) is checked before the in-memory CLI_CONFIG dict.

Problem

hermes config set delegation.model X writes to disk and reports success, but _load_config() in delegate_tool.py checks the in-memory CLI_CONFIG dict first. Since CLI_CONFIG was loaded once at process startup and never invalidated, the stale cached value wins — the new disk config is never read until the process restarts.

This affects CLI, gateway, and cron — any long-running process that calls delegate_task() after a config change via hermes config set.

Root Cause

_load_config() prioritized CLI_CONFIG (stale in-memory dict) over load_config() (mtime-cached disk reads with automatic invalidation). The load_config() function in hermes_cli/config.py already handles cache invalidation correctly by checking (mtime_ns, size) on every call — it just was never reached because CLI_CONFIG was checked first.

Fix Details

• Try hermes_cli.config.load_config() first (mtime-aware, always fresh)
• Fall back to cli.CLI_CONFIG only if load_config() fails
• Added if cfg: guard to the CLI_CONFIG path for consistency

Testing

1. Start a gateway session with delegation.model: google/gemini-2.5-flash
2. From another shell: hermes config set delegation.model google/gemini-3-flash-preview
3. Call delegate_task(...) from the original session
4. Before fix: subagent uses gemini-2.5-flash (stale cache)
5. After fix: subagent uses gemini-3-flash-preview (fresh from disk)

Fixes #18946