Bug: Use one provider resolution plan for dispatch, hashing, and provenance #110

Summary

For engine_id=fal_ai, model=sdxl-turbo, the hash/provider resolver selected Fal, but creative_runner.py:627 dispatched to SiliconFlow when both dummy keys were available. The resolver and executor contain separate heuristic decision trees.

Environment and evidence

• Review finding: F10 (2026-10-05 product/technical review).
• Baseline: Windows, dev at c1c5dbe. The remote dev matched this commit when filing.
• Evidence: Reproduced.
• Priority recommendation: P1 - proposed first-release blocker. This is review triage, not a production-incident severity declaration.
• No real credentials, paid inference, engine installation, or unrelated process termination were used for review probes. Mocked observations establish the stated code behavior, not live-provider/GPU acceptance.

Reproduction or validation

1. Construct a txt2img request with engine_id=fal_ai, model=sdxl-turbo, and seed=42.
2. Mock both credential lookups with dummy values and mock Fal/SiliconFlow calls.
3. Compare resolve_effective_provider(request) with CreativeRunner._run_cloud dispatch.
   Observed: resolver=Fal; executed mock=SiliconFlow. No paid API call was made.

User impact

The selected provider, actual service, credential use, cache identity, and provenance can diverge. This also affects users' expectations about cost and asset destination.

Proposed approach

Resolve a single capability-checked execution plan before submission and use it for validation, dispatch, hashing, UI disclosure, and provenance. Reject unsupported combinations rather than silently switching providers.

Acceptance criteria

• Resolve one capability-checked execution plan before submission.
• Dispatch, cache keys, provenance, and UI disclosure use that same plan.
• Explicit provider selection cannot silently switch to another service.
• Tests cover multiple configured providers and unsupported model/action combinations.

Related work

Related closed issue: #59. The earlier missing-provider-hash issue is closed. This report concerns disagreement between the resolver now used for hashing and the actual dispatch tree.

Verification scope

Real GPU inference, paid-provider compatibility, and a clean-machine packaged desktop journey remain unverified. Any follow-up implementation should target dev under the repository's contribution/branching rules.