managed_image_partner inlined the dispatcher's strip-or-None reading of
image_gen.provider/model; managed_route now normalises raw values itself,
so both callers pass config values straight through and cannot drift.
_managed_model_plugin's docstring points at managed_route instead of
restating the rule, and NOUS_MANAGED_PROVIDER is a top-level import (no
cycle). A Krea style reference that disappears between is_file() and open()
now returns invalid_image_url instead of raising. Test comment corrected:
only managed-model routing ignores legacy use_gateway.
The routing rule (direct vendor -> none; Krea id -> Krea; Portal id -> Portal
only under an explicit `nous`, else FAL) lived in _managed_model_plugin and
was copied into managed_image_partner, where it read the provider through
_selected_provider: lowercased and legacy use_gateway: true counted as
`nous`. The dispatcher does neither, so e.g. use_gateway + a Portal id was
labelled "Nous Portal" while generating on FAL. Both now call
tools.image_generation_managed.managed_route() with the stored values read
the same way. Dispatch behaviour is unchanged.
`image_gen.provider: nous` fronts three gateways; the stored model id now says which
one serves a request (tools/image_generation_managed.py): FAL catalog ids → FAL gateway,
Krea plugin ids → Krea gateway, anything else → the Nous Portal image plugin. Before,
a Portal model id under the managed selection fell through to FAL, which warned about
an unknown model and billed a FLUX default instead.
The same module builds the managed row's union catalog with each model listed once
(FAL wins identical/cross-id duplicates; Krea 2 appears natively, never as the FAL or
Portal copy), so the picker and the runtime agree on one mapping.
