fix: correct Codex MCP TOML format, fix Windows HOME fallback (#18)

[johnintuit]

Codex expects [mcp_servers.infigraph] as a sub-table, but install_toml_target was writing [mcp] with an inline table — Codex never saw the entry. Also escape backslashes in Windows paths so generated TOML actually parses.

Separately, infigraph-mcp read HOME directly with no USERPROFILE fallback in 7 places (registry lookups, mcp.log path, instance lock, group reindex) — broken on Windows where HOME is typically unset. Now falls back to dirs_next::home_dir() like infigraph-core already does.

Summary

Test plan

• cargo test --all passes
• cargo clippy --all-targets passes
• Tested manually (describe below)

Notes

[abdul3asith]

Tested PR #27 at edec512b on macOS 15.2 with Rust 1.97.1 and Codex CLI 0.144.5.

I completed both automated and manual testing. The focused TOML install/uninstall tests passed, and after removing my previous manual registration and running the PR-built infigraph install, Infigraph appeared correctly as enabled in codex mcp list. The generated configuration used [mcp_servers.infigraph] as expected.

cargo test --all encountered one unrelated, pre-existing failure involving get_compression_stats missing from MCP_TOOL_NAMES. The same issue exists on current upstream/main and has a separate fix in f1912e6.

The Codex MCP fix works correctly in my macOS environment.

[johnintuit]

@murari316 can you pls approve

[johnintuit]

@murari316 can you pls approve?

[murari316]

Reviewed diff in full — Codex TOML section fix and Windows HOME->dirs_next fallback across 7 sites, all consistent and covered by new tests (escaping, section preservation, actual TOML parse roundtrip). Approving.