fix: surface failed component list loads in expose components form

[0717lee]

Closes #6549

Summary

In the expose step, the three component lists are loaded with useQuery but only data, isLoading, and refetch are destructured — error is never read. A failed /tools, /resources, or /prompts request therefore renders identically to a successful empty one: the section shows "0 tools" / "0 resources" / "0 prompt templates" and invites pressing "Expose components" on what looks like a server offering nothing.

• Each section now reads its own query error. When a load fails, the count line shows "Failed to load …" in the app-wide error tone (via STATUS_TONE_CLASS) instead of a zero count, and the section renders an error InlineNotification with the API error message and a Retry action that refetches just that list.
• Sections whose own request succeeded keep showing their real counts, including legitimate zeros — a connected MCP server that exposes no tools, resources, or prompts is not an error, and must keep rendering as it does today.

Unit tests cover the failed/empty distinction, per-section independence (some sections fail while others keep their counts), and recovery through Retry.

[gcgoncalves]

Thanks @0717lee for this PR, the error handling is a nice improvement to the form. There are a couple suggestions for the proposed implementation:

First, it'd be nice to improve i18n (see comment below). Also, when a user clicks Retry for the tools section, toolsLoading becomes true. Then, the entire form is replaced by a spinner, including the resources and prompts sections, that are still valid.

My suggestion is using the individual loading states to add guards to each section:

  {toolsLoading ? (
    <span className="text-sm text-muted-foreground">
      {intl.formatMessage({ id: "common.loading" })}
    </span>
  ) : toolsError ? (
    intl.formatMessage({ id: "gateways.exposeComponents.error.tools" })
  ) : (
    intl.formatMessage({ id: "gateways.card.toolCount" }, { count: toolCount })
  )}

[0717lee]

Thanks for the review @gcgoncalves — both points addressed in 79cdee2:

1. i18n: the load-failure strings are now message keys — gateways.exposeComponents.error.{tools,resources,prompts} plus *WithDetail variants for the inline notifications, landed in en-US, pt-BR, and es-ES. The section counts reuse the existing gateways.card.toolCount/resourceCount keys; prompts got a new gateways.exposeComponents.promptCount key to keep the current "prompt template(s)" wording.

2. Per-section loading: each section's count row now renders loading → common.loading / error → error key / otherwise count, and the form-level spinner only covers the initial load (before any section has resolved). Retrying tools no longer replaces the still-valid resources/prompts sections with a spinner.

Added a regression test ("should keep healthy sections mounted while a failed section retries") that pins this: during a hanging tools retry, the other sections stay mounted and no form-level spinner appears. Full vitest (3324 passed), tsc -b, and the locale parity checks are green.

[0717lee]

Thanks for the catch — I've localized the Retry action label as well.

Changes:

• Added common.button.retry to en-US, pt-BR, and es-ES common locale files.
• Replaced the inline "Retry" labels in ExposeComponentsForm.tsx with intl.formatMessage({ id: "common.button.retry" }) for the tools, resources, and prompts error-state retry actions.

Verification:

• npx vitest run on ExposeComponentsForm.test.tsx and locales.test.ts passes.
• npx tsc -b passes.
• Prettier/ESLint checks pass.

Pushed as d45fdbf on fix/expose-components-error-state.