* fix(agent): give magpie's provider table the actor-authorization header
Codex offers its built-in image tool (image_gen.imagegen) — and the other
OpenAI-provider tools — only to a provider it reads as the OpenAI actor:
ModelProviderInfo::uses_openai_actor_authorization(), i.e. a provider that
does not require OpenAI auth but carries x-openai-actor-authorization.
magpie writes [model_providers.magpie] but carried neither signal, so a
Codex on magpie was never given the tool and could not draw through a
Codex backend such as sub2api's.
Write http_headers = { "x-openai-actor-authorization" = "magpie" } into
that table. magpie does not forward the header upstream: codexHeader
rejects anything naming "authorization".
Test: TestCodexMagpieProviderCarriesActorAuthorization.
* gateway/provider: let a Responses-only relay (Codex backend, sub2api) draw
A provider added as 'OpenAI Responses' only (what a Codex backend such as
sub2api speaks) has no chat base, so Drawers() returned nil before ever
looking at the vendor's list, draw() refused with 'can't draw', and
drawImages() posted to an empty base. The vendor's own /v1/models does list
its image models (sub2api serves gpt-image-2.5), and they are meant to be
picked in Settings → Images.
- Drawers: a Responses-only provider draws when it has any OpenAI-shaped
base, not only a chat one.
- draw: refuse only when neither Chat nor Responses is set.
- drawImages: fall back to the Responses base when there is no chat base.
- List: the add form's 'Fetch models' keeps the vendor's image models so
one can be picked while the provider is added.
Tests: TestResponsesOnlyProviderDraws, TestListOffersImageModels.
* fix: route Codex native images through its turn provider
---------
Co-authored-by: yetone <yetoneful@gmail.com>
