Follow-up to #82 / #83.

Bug

After #83 merged, fresh hermes --provider X --model Y invocations leave config.yaml without any mcp_servers.hermes-internal entry. Worker boots with zero G2/G3/G4 MCP tools — same symptom #82 was supposed to fix.

Root cause

#83 placed the ensure_internal_mcp_server() call in tui_gateway/entry.py. That file is only on the path when the TUI gateway subprocess spawns (i.e., interactive TUI shell active). Direct hermes … CLI invocations land in hermes_cli/main.py:main per [project.scripts] hermes = "hermes_cli.main:main" — never touch tui_gateway/entry.py — so the autowire never fires.

Fix

Add the autowire call inside hermes_cli/main.py's CLI startup block (between discover_plugins() and discover_mcp_tools(), around line ~12756). The block is gated on args.command in {None, "chat", "acp", "rl"} — covers bare invocation, chat, acp, rl. Order matters: autowire must run before discover_mcp_tools so the freshly-written entry is visible on the same boot.

Keep the tui_gateway/entry.py call from #83 — it's correct for the TUI-gateway subprocess path. Idempotent: calling both is safe.

Acceptance

• Fresh hermes --provider X --model Y invocation writes mcp_servers.hermes-internal to active profile's config.yaml.
• Same HERMES_DISABLE_INTERNAL_MCP=1 opt-out applies.
• Worker can invoke grafted_context_fetch post-fix without operator wiring.

Severity

Blocks the original #82 acceptance for the most common invocation shape (direct CLI). #83 only delivered the fix for the TUI-gateway path.