Add Requesty as an image generation provider

[Thibaultjaigu]

This adds Requesty as an image provider, mirroring the existing OpenRouter image provider.

Requesty (https://router.requesty.ai/v1) is an OpenAI-compatible router that serves image models via /chat/completions (returning an image URL), the same shape this repo already uses for OpenRouter.

Changes:

• internal/image/requesty.go: new RequestyProvider mirroring the OpenRouter one.
• internal/image/provider.go: a requesty registry entry with verified image models (google/gemini-3.1-flash-image-preview default, vertex/gemini-2.5-flash-image) + factory case.
• internal/config/config.go, tests, and docs.

I used only Requesty-verified image model ids (OpenRouter's ids aren't all served). Verified: go build ./..., go vet, go test ./internal/image/ ./cmd/... pass.

I work at Requesty. This mirrors the existing OpenRouter provider as closely as possible. Happy to adjust or close it if it's not a fit.

[geekjourneyx]

Thanks for the contribution — adding Requesty through the provider registry is a reasonable fit, and the response/data-URL path broadly matches the existing OpenRouter integration. I don't think this is merge-ready yet, though.

Recommendation: request changes / do not merge yet.

Blocking

1. Please rebase and resolve conflicts against current main. GitHub currently reports mergeable_state: dirty / rebaseable: false. The branch is based on 56c714e, while provider defaults, discovery tests, docs, and release metadata have moved since then; conflict resolution must preserve those newer changes.

2. The registered model IDs do not match Requesty's current documented image-generation contract. The PR uses:

   • default: google/gemini-3.1-flash-image-preview
   • alternate: vertex/gemini-2.5-flash-image

   Requesty's current Image Generation documentation lists vertex/gemini-3.1-flash-image-preview and vertex/google/gemini-2.5-flash-image-preview for the chat-completions path. Because the default is duplicated across the registry, config defaults, docs, and tests, a stale ID makes the out-of-box provider path invalid. Please verify the IDs against the live Requesty model catalog, then update all four layers together. The official request example also omits modalities; please either align the payload or add an API fixture/smoke result demonstrating that modalities: ["image"] is accepted.

3. Requesty must not reuse mapSizeToOpenRouter unchanged. Requesty's documented dimensions differ from OpenRouter's table. For example, Requesty documents 1376x768 for 16:9 at 1K, but this implementation only recognizes 1344x768; 1376x768 silently falls back to 1:1 / 2K. Likewise, GetRequestySupportedImageSizes() advertises 1K, 2K, and 4K, but passing 1K through the current mapper also becomes 1:1 / 2K. Please add Requesty-specific size parsing/validation and reject unsupported values instead of silently changing aspect ratio/resolution. Also reconcile the product default of 2K with Requesty's documented API default of 1K.

4. Add contract-level coverage and run the repository gates. The provider unit tests are useful, but the changed contracts still need tests for:

   • requesty and rq registry/factory lookup;
   • config-file/env defaults (base URL, model, size) and missing-key rejection;
   • providers list --json / providers show requesty --json;
   • current documented Requesty dimensions, unsupported-size rejection, malformed JSON/data URLs, and provider error propagation.

   This head has no CI/status checks. After rebasing, please run gofmt -l ., go vet ./..., make quality-gates, and GOCACHE=/tmp/md2wechat-go-build go test ./... as required by the repository workflow.

Non-blocking improvements

• requesty.go duplicates almost the entire OpenRouter implementation. A small shared chat-image transport/data-URL/temp-file helper would reduce future drift while keeping provider-specific models, sizing, and errors separate.
• Normalize a custom base URL before appending /chat/completions so a trailing slash does not produce //chat/completions.
• The PR description says Requesty returns an “image URL,” while the implementation intentionally accepts only a base64 data URL. The current Requesty chat-completions docs show a data URL, so please make that wording explicit; if HTTPS image URLs are also part of the contract, handle and test them separately with bounded downloads.
• Preserve Requesty's error message/code where possible; mapping every 403 to payment_required can hide policy/model-access failures.

The README/CONFIG/DISCOVERY/AGENT-GUIDE/IMAGE_PROVISIONERS/CHANGELOG coverage is otherwise in the right areas. Once the API IDs, sizing semantics, rebase, and contract tests are fixed, this should be straightforward to re-review.