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 a caller can
tell an inherited declaration from the tenant's own without a second call.

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

The registry read at ../workload-identity/issuers answers a different
question — what this tenant may edit and withdraw — and a form that offered its
answer would omit every deployment-scoped issuer, which on a deployment that
declares its issuers centrally is the whole list.

There is no enabled filter, and that is deliberate. Enabling is a

separate verb and the supported order of work is declare, bind the workloads, then
enable; withholding a declared-but-not-yet-enabled issuer here would hide exactly
the rows an operator is in the middle of setting up. A withdrawn (soft-deleted)
declaration is not returned, which is the one filter this read and the runtime
verification path share.

displayName is null on an inherited row. It is a label

a platform operator wrote for their own purposes; the row's identifying fact here
is its canonical issuer URL.

Ungated. A tenant whose edition does not include workload identity may

still read this list — reading which issuers exist is not the act that grants a
workload access, and the refusal it will meet at submit is the one that states the
real reason.