Every trusted-issuer declaration a binding for THIS TENANT may name: the ones the
DEPLOYMENT declares, which every tenant inherits, concatenated with the ones this
tenant declared for itself. Each row carries scope, so an operator can
tell an inherited declaration from the customer's own without a second call.

🔴 It is the set the bind call accepts, not the tenant's own registry.

The registry read at ../workload-identity/issuers answers what this
tenant may edit and withdraw; an onboarding form offering that answer would omit
every deployment-scoped issuer, which on a centrally declared deployment is the
whole list.

No enabled filter: the supported order of work is declare, bind the

workloads, then enable, so a declared-but-not-yet-enabled issuer is bindable and is
returned. A withdrawn (soft-deleted) declaration is not.

displayName is null on an inherited row — it is a

label written for the deployment's own purposes and is not part of what this tenant
is being shown.

The ROOT tenant is a valid target for this READ, unlike on the write. A read creates no row and emits no audit, so the ROOT-target refusal has nothing to protect.

Not entitlement-gated. The operator is the party that sells the edition,

so refusing them on it would be the platform refusing itself.