refactor(runtime): add transport profiles for provider execution

[Allmight97]

Summary

• add explicit runtime transport profiles so execution can be resolved from provider + model
• generalize OpenAI Responses support beyond the Codex-specific path
• add transport adapters for Anthropic Messages and Google GenerateContent while preserving existing provider behavior

Why

Hermes currently resolves one runtime protocol per provider. That works for providers like OpenRouter or Codex, but it is too narrow for providers whose supported protocol depends on the selected model family.

OpenCode Zen is the motivating case:

• GPT models use OpenAI Responses
• Claude models use Anthropic Messages
• Gemini models use Google's GenerateContent transport
• other OpenCode models use OpenAI-compatible chat completions

Without an explicit transport profile, Hermes cannot add first-class OpenCode support cleanly.

What changed

• add hermes_cli.transport_profiles with explicit transports and legacy api_mode compatibility
• route runtime resolution through transport profiles instead of provider-wide api_mode assumptions
• add lightweight protocol adapters in agent.transport_adapters for:
  • Anthropic Messages
  • Google GenerateContent
• keep existing providers behaviorally unchanged unless a caller opts into the new transport metadata
• preserve current Codex tests and backward-compatible wrapper methods while shifting Responses handling to a generic transport path

Validation

• ./.venv/bin/python -m py_compile hermes_cli/transport_profiles.py hermes_cli/runtime_provider.py agent/transport_adapters.py run_agent.py cli.py gateway/run.py cron/scheduler.py tools/delegate_tool.py
• ./.venv/bin/pytest tests/test_runtime_provider_resolution.py tests/test_transport_adapters.py tests/test_provider_parity.py tests/test_run_agent_codex_responses.py tests/test_cli_provider_resolution.py tests/test_api_key_providers.py -q

Notes

• This is the enabling layer for first-class OpenCode Go / OpenCode Zen support.
• Follow-up provider/onboarding support is prepared separately so the runtime abstraction stays reviewable on its own.
• This follows the design concerns raised in feat(provider): add OpenCode Zen and OpenCode Go providers #765 without changing existing provider UX in the same PR.

[teknium1]

Thanks for the work on this, @Allmight97! Unfortunately this PR is 270 commits behind main and conflicts fundamentally with changes that have landed since it was branched.

What happened: Native Anthropic support was independently implemented on main via agent/anthropic_adapter.py (615 lines) using the official Anthropic SDK — with OAuth/Claude Code credentials, interleaved thinking, prompt caching, token refresh, and full streaming. The api_mode = "anthropic_messages" routing is now deeply integrated across run_agent.py (~21 code paths).

Why this can't merge:

• The PR's AnthropicMessagesClient (raw httpx) duplicates and downgrades the existing SDK-based adapter
• The LEGACY_API_MODES mapping (anthropic_messages → chat_completions) would break all existing Anthropic routing
• The transport abstraction is redundant with the existing api_mode system that already handles protocol routing

If OpenCode Zen/Go support is desired: It should be built as a standard provider directly on the existing api_mode system, following the "Adding a New Provider" workflow in the codebase. No transport abstraction layer is needed — api_mode already routes between OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages.

The rename of _codex_* → _responses_* methods was a good idea — if you'd like to submit that as a smaller standalone PR against current main, it would be welcome.