fix(generate): provenance names the model that ran, not the slot's

[tobert]

Found live tonight, running the pre-tag checks against the shipped binary. A generate
with op: "flux-dev" wrote this beside the artifact:

{ "prompt": "…", "model": "bfl/flux-2-pro", "cast": "flux", "tool": "generate" }

The op resolved correctly and the call really did go to /v1/flux-dev
(bfl.rs:191 — request.op.as_deref().unwrap_or(slot_model), with tests already
covering it). Only the record was wrong. So the one file an operator reads months
later, to decide whether an artifact can be trusted or reproduced, named a model that
never ran — and at BFL's per-request pricing, a different cost.

The rule was already written down, and enforced one door over

generate refuses fields.model with this reasoning (server/mod.rs:3173-3177):

Reserved keys: recorded provenance must describe the request that actually ran. […]
fields.model would reroute the call while the sidecar records the slot's model — so
both are refused loudly.

op reroutes exactly the same way and walked straight past that guard. This closes the
hole op opened, with the same principle the existing guard states.

Fixed where the asymmetry lives

Not by special-casing BFL in the handler. MediaModel::effective_model defaults to
None — "the cast's image slot already names it" — which is true for every provider
whose ops are routes over one model: Stability's edit/inpaint, the Images API's
edits. BFL overrides it, because its ops are model ids (flux-dev, flux-2-pro).

That is the same fail-closed shape as accepts_inputs and accepts_ops sitting beside
it: a provider added later that reroutes and forgets to say so gets the safe answer — a
slot ref — rather than a confidently wrong model.

MediaArm::recorded_model recomposes onto the slot's backend so the record keeps its
backend/model shape, splitting on the first / only, since a model id can contain
more (crusoe/deepseek-ai/Deepseek-V4-Flash).

All five places the handler names a model now name the one that ran: the sidecar, the
footer the caller reads, the span (cost attribution), and the deferred lane's job label
and handle message.

Two tests, teeth checked on both

test	proves	fails when
bfl::…::the_recorded_model_is_the_op_that_ran_not_the_slot	BFL resolves the op as the model	the override is dropped
server::…::generate_records_the_model_an_op_rerouted_to_not_the_slot	the handler carries it to what an operator reads	the handler reverts to slot_ref

The first carries a control arm for the no-op case, so an impl that always answered
"flux-dev" would fail it. Both teeth were run, not assumed.

Suite 1331 passed / 0 failed, clippy clean.

Scope notes

No changelog entry. BFL and op are both new in this same unreleased section, so this
bug has never been in a release — the feature bullet describes the behavior that ships.

Not fixed here, deliberately: a Stability op names a route, not a model, so the
slot ref stays the honest answer there. Recording the route as well would genuinely
improve the sidecar, but that is an added field rather than a correction, and it is not
what tonight found.

Also noticed, not addressed: the CLI's generate has no --op flag, so this path is
reachable only over MCP. Worth its own look, separately.

🤖 Generated with Claude Code