feat(image-gen): honor image_gen.model from config.yaml in plugin dispatch

[kowenhaoai]

Summary

The image generation tool dispatches to plugin providers without a model argument, leaving the plugin to pick its default. Users on OpenRouter, ComfyUI, or custom backends have no config-level way to select a specific model — they have to fork the plugin or patch the tool.

Change

• Add _read_configured_image_model() that reads image_gen.model from the active profile's ~/.hermes/config.yaml (profile-aware via get_hermes_home()).
• In _dispatch_to_plugin_provider(), forward the resolved model into the plugin's generate(**kwargs) call.
• When image_gen.model is unset, the plugin falls back to its own default, so existing users see zero behavior change.

Config example

image_gen:
  provider: openrouter
  model: flux-pro          # NEW — forwarded to the plugin

Test plan

• pytest tests/tools -k image -q → 170 passed, 7 skipped.
• Manual: set image_gen.model: flux-pro, run hermes image-gen "..." — the plugin receives flux-pro.
• Manual: unset image_gen.model — plugin uses its own default (backward compatible).

Risk

Low. Purely additive: missing config → unchanged behavior. The only new code path is an opt-in config read.

[kowenhaoai]

Hi — polite maintainer ping on this one when you have a moment. 🙏

Context: this is the companion to #19375. It's purely additive (opt-in via image_gen.model in config.yaml), so it should be a safe review. Happy to adjust the config key naming, plugin contract, or anything else if you prefer a different shape.

Thanks!

[kowenhaoai]

Flagging a related pair while doing due-diligence on duplicates: #18793 (issue) + #18796 (fix). They tackle an adjacent slice of the same problem — third-party OpenAI-compatible backends that need a non-default model identifier.

The design choices are different:

	This PR (#19376)	#18796
Layer	Tool dispatcher (tools/image_generation_tool.py)	Plugin-internal (plugins/image_gen/openai/)
Config key	image_gen.model (applies to every plugin via generate(..., model=...))	image_gen.openai.api_model (only OpenAI plugin)
Scope	One key, all providers	Per-plugin namespace

They're not strictly conflicting — mine adds a tool-level pass-through, #18796 adds plugin-internal resolution for OpenAI specifically. But if the maintainer prefers one style over the other, some consolidation might make sense. No strong opinion from my side; happy to:

• rebase to align with fix(plugins): support OPENAI_IMAGE_API_MODEL env var + base_url config for third-party backends #18796's style (per-plugin config) if you prefer plugin-scoped,
• drop this PR if fix(plugins): support OPENAI_IMAGE_API_MODEL env var + base_url config for third-party backends #18796's approach covers the underlying need adequately,
• or keep both as they solve slightly different problems (this one is generic, fix(plugins): support OPENAI_IMAGE_API_MODEL env var + base_url config for third-party backends #18796 is OpenAI-specific).

The original issue #18793 actually lists "Option A: Allow image_gen.openai.model to serve as the actual model field in the API request" — this PR is closest to the tool-level version of that idea, since I forward image_gen.model into the plugin's generate() call as a model= kwarg.

Not asking for a decision right now — just tagging the thread so reviewers have the full picture.