The datasources panel offers one provider by name and never reads the catalog, so a provider the host admits cannot be connected from any surface #1238

What we are trying to do

A person administering a deployment opens the datasources panel and connects whatever source the host actually admits. Today the panel offers one provider by name and makes no catalog call, so a provider the host accepts cannot be reached from any surface that uses the panel, and a provider the host refuses is still offered.

The panel lives in packages/saas-ui precisely so there is one of it rather than a copy per consumer, and a consumer that imports it owns none of it. So this change reaches every surface at once, with no change in any consumer.

What exists

• DatasourceService.GetDatasourceCatalog reports each provider and whether it admits new sources, with the reason when it does not. No client calls it. (#1211 found this; it is the gap that record names first.)
• packages/saas-ui/src/datasources/datasources-panel.tsx:602-605 renders a connect action naming one provider.
• The kit's datasource client has no catalog method.
• packages/saas-ui/src/datasources/schema.ts holds the panel's schemas.

The change

1. The kit's datasource client gains the catalog call.
2. The panel renders the providers the catalog reports, each with the fields that provider needs, and names the reason a provider is not connectable instead of hiding it. A provider the host does not admit must be visible and refused with its reason, not absent — a person who cannot see why a thing is missing files a support request.
3. The fields are per provider and come from the provider's own descriptor rather than a table in the panel, so a new provider needs no panel change. Where a provider needs a prefix, include and exclude patterns, and a credential, those are its fields, not the panel's vocabulary.
4. A credential a person types is passed to the operation and never persisted by the panel, logged, or kept in component state after the call.

Acceptance

1. With a host whose catalog admits more than one provider, the panel offers each, and connecting through each calls AddSource with that provider's own fields.
2. With a host whose catalog refuses a provider, the panel shows it and states the refusal reason verbatim from the catalog.
3. No provider name is hardcoded in the panel. Removing a provider from the host's catalog removes it from the panel with no code change.
4. The kit's own suite and preview harness cover both the admitting and refusing cases.
5. A consumer compiles unchanged. The panel's props must not gain a required field, because every consumer passing today's props must keep working.

Why now

This is the last piece between a proven mechanism and something demonstrable. An object-store provider is being made connectable in #1211 / #1235, and the supporting service released its per-call binding. With the catalog read in place, a surface that already uses this panel gains that provider with no change of its own. Without it, the capability exists and nobody can reach it.

#1235 credits itself with this work and does not contain it, which its independent review caught. That PR is already at review size with open findings, so this lands separately rather than growing it.

Constraints

About 500 hand-written lines; tests count apart; past 2,000 stop and ask. Additive only: no existing export changes shape and no prop becomes required. Kit-version rule for the bump. This repository is public and must name no consumer, product or customer anywhere, including in fixtures and commit messages. No release or publish.