What this connection could ingest, plus what it is narrowed to.

account_id picks one connection when the tenant holds several to the same provider (CLO-528); omitted, this is the pre-existing "most recently connected wins" behavior.

Both halves in one response on purpose: a picker needs the available list and the current selection to render, and fetching them separately would let it draw a stale set of checkboxes against a fresh list.

selected is null when the connection is not narrowed, which the UI must render as "all of them" rather than as "none" — the two are different states and conflating them is how a picker silently turns ingestion off.

Each row also carries sync: that resource's own last outcome, in the same vocabulary GET /{provider}/connection returns, so a caller reading both does not learn two shapes for one fact. It is null when nothing is known — never dispatched, or connected before per-resource outcomes were recorded — which is not the same as pending: one means "we have never asked", the other "we asked and are waiting". A picker that renders them alike reports a resource as in flight forever.

Known gap: a resource whose health was recorded and which the provider no longer lists (an installation dropped it) does not appear here at all, and its entry stays in the column. Pruning belongs to the write path that knows an id is gone for good, not to a read.