fix: honor force_ipv4 in run_agent and legacy cli bootstrap

[LeonSGP43]

Summary

• add a small helper that reads network.force_ipv4 from config.yaml and applies the existing socket patch
• call that helper during run_agent.py and legacy cli.py bootstrap so hermes-agent and python cli.py honor the same workaround as hermes
• extend the IPv4 regression tests to cover config loading plus both uncovered entry points

Testing

• pytest -o addopts='' tests/test_ipv4_preference.py -q
• ruff check hermes_constants.py run_agent.py cli.py tests/test_ipv4_preference.py
• git diff --check

Fixes #37662

[teknium1]

Thanks for tracing this to the uncovered bootstraps. The premise is still valid on current main: run_agent.py:125-127 and cli.py:180-182 load their Hermes state without applying the preference, whereas hermes_cli/main.py:572-605 does.

Problems

• The new helper dereferences config.get(...) after yaml.safe_load() without confirming that the YAML document is a mapping (hermes_constants.py:470 in this PR). A valid scalar-root config can therefore raise during either newly added import-time call.
• The helper reads raw user config but bypasses the managed-scope overlay that the canonical bootstrap applies at hermes_cli/main.py:561-574. That would make these entry points disagree when an administrator pins network.force_ipv4.

Suggested changes

• Guard non-mapping YAML roots and add a scalar-root regression test.
• Apply the managed-scope overlay before reading network.force_ipv4, with coverage for an administrator-pinned value.

Automated hermes-sweeper review.

[teknium1]

yaml.safe_load() may return a scalar or list for valid YAML. Guard config with isinstance(config, dict) before this access; otherwise this import-time helper can raise and prevent run_agent or cli from starting when config.yaml has a non-mapping root.