fix(image_gen): gate openai-codex image generation on Codex tool support

[izumi0uu]

What does this PR do?

Fixes a false-positive availability bug in the openai-codex image generation provider.

Before this change, the provider could appear available as soon as Codex auth credentials were present, even when the current Codex backend did not actually expose the image_generation tool. That led to confusing runtime failures when Hermes tried to force the tool through the Responses API.

This patch makes the provider capability-aware so unsupported Codex surfaces are treated as unavailable or reported with an explicit capability error instead of a generic API failure.

Related Issue

Fixes #49008

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✅ Tests (adding or improving test coverage)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Added Codex image-generation capability detection to the openai-codex image provider.
• Used cached/local Codex model metadata as the cheap availability signal.
• Added a live model-capability probe during generation when a definitive answer is needed.
• Mapped the known unsupported-tool backend failure into capability_unsupported.
• Updated provider availability behavior so unknown or unsupported Codex surfaces no longer report as available.
• Added regression coverage for cached support, unknown capability, unsupported capability, and plugin dispatch behavior.

How to Test

1. Run:

   scripts/run_tests.sh tests/hermes_cli/test_image_gen_picker.py tests/tools/test_image_generation_plugin_dispatch.py tests/plugins/image_gen/test_openai_codex_provider.py -- -q

2. Confirm the targeted suite passes.

3. Verify that openai-codex availability now depends on confirmed image_generation support instead of token presence alone.

4. Verify that unsupported Codex tool surfaces return capability_unsupported rather than a generic API error.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run the targeted tests above and they pass
• I've added tests for my changes
• I've tested on my platform:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Remaining Risks

• This change is validated with targeted automated tests.
• I did not run the full Hermes suite for this patch.
• Live backend behavior is inferred through the provider contract and the targeted unsupported-tool regression path rather than broad end-to-end matrix testing.

[teknium1]

Thanks for the careful capability analysis and regression coverage. This is an automated hermes-sweeper review; the reported failure is already handled on current main.

• 402969670d84f01021c3bb19db438a8733a7964f added account-specific classification for the exact Codex HTTP 400 rejection.
• plugins/image_gen/openai-codex/__init__.py:56 recognizes the exact unsupported image_generation tool-choice response, and :577 returns capability_unsupported with a targeted alternative-provider message.
• a10081f83bf8b5c918262a5ff039ba0c91ce3ad7 added HTTP-boundary regression coverage in tests/plugins/image_gen/test_openai_codex_provider.py.

The implementation uses the PR's stated acceptable outcome—an explicit capability error instead of a generic API failure—on the definitive generation path.

[teknium1]

Correction — this PR was closed for the wrong reason, and I want that on the record.

It was closed as implemented_on_main, citing commit 402969670d as "a later, more precise account-capability classification." That classifier was itself the problem. It matched the HTTP 400 Tool choice 'image_generation' not found in 'tools' parameter and translated it into "Image generation is not enabled for the current Codex account. Switch the image provider to OpenAI API key, FAL, or xAI."

But that 400 is a request-shape rejection — the Codex backend resolves tool_choice as a function-tool name and never recognizes hosted-tool entries, so it fired for every account on every request. We were sending a payload the backend always rejects, then telling users their ChatGPT plan lacked the feature. It sent people away from a provider that had never actually been tried, and it's why this stopped being reported as a bug.

I removed that classifier in #71635 (064b6e40c5) and landed the actual request-shape fix (@Tranquil-Flow's #19979, the earliest submission). HTTP failures now surface verbatim.

Your PR was pointed at the right area and closing it against that classifier was a mistake on our side. The direction we ultimately took differs from this PR — rather than surfacing a clearer "unsupported" error, we fixed the request so the failure stops happening, and deliberately stopped interpreting provider errors at all on this path. So this stays closed, but as "superseded by a different fix," not "already handled." Thanks for the work, and sorry for the bad close reason.