AI Power-Ups: image enrichment and the model-role fallback fail silently

Two places where AI Power-Ups does the right thing internally and tells nobody. Found while manually testing the capabilities work in #5693 against a deployed API.

What already works, so nobody re-investigates it

CMS entry generation reports failures properly. Configured a connection with a deliberately invalid key, hit Generate, and got a toast: "Failed to generate content — AI generation failed: API key is invalid." CmsGenerateEntryContentTask calls sendErrorToUser and the admin renders it. WbGeneratePageContentTask has the same machinery.

1. Image enrichment swallows a config failure

packages/ai-powerups/src/api/features/AiImageEnrichment/AiImageEnrichmentTask.ts:87

When ResolveAiCapabilityUseCase fails (no connection, no key, no model on the role), the task logs a warning and returns controller.response.done(...). done, not error. The task reports success, the uploaded file gets no alt text, title or tags, and the only trace is a server-side log line nobody is watching.

The resolver already produces a message naming the exact screen to fix ("Pick one under Settings → AI Power-Ups → Model roles"), so the text exists and is simply not delivered anywhere a user can see it.

This is the case Pavel called out by name in the design doc: "we'll need to provide some meaningful notifications to the users if there's a missing config, for example, in File Manager image enrichment."

2. The role fallback is invisible

ResolveAiCapabilityUseCase returns fellBackToStandard: true when a capability asks for a role that has not been filled in and standard answers instead. Nothing reads it — the field is computed and dropped.

In practice: a capability declaring vision runs on the Standard model when Vision is empty. If Standard is not multimodal the request fails for a reason the settings screen gave no warning about, and if it is multimodal it silently costs more than the user intended. The Capabilities tab says "Empty means inherit" but never shows what was actually inherited at run time.

Worth deciding together

This overlaps an open question on the design doc: whether Vision should fall back to Standard at all, or whether an unconfigured role should disable the capability (Pavel's position). Surfacing the fallback and surfacing the missing-config case are the same piece of work, and doing it would make the fallback defensible rather than silent.

Related: the settings screen could also mark a capability that cannot currently resolve, rather than leaving the user to discover it at the point of use.