Customer-facing member roster row.
Includes uid and ssh_authorized_keys deliberately, unlike
frontierCluster.ts's teamSlurmMemberSchema.omit(...) — neither is
secret (an SSH public key is meant to be shared; the POSIX uid is
an internal identifier, not a credential), and both are genuinely
useful for troubleshooting ("which key is this teammate's login
actually using", "does this uid match the file ownership I'm
seeing"). The dashboard's redaction was about what its roster
component happened to render, not a security boundary — this is a
deliberate, considered divergence from strict TS parity, not an
oversight.
There is no per-member group id anywhere in this system's data
model to expose alongside uid — group assignment, if any, is an
internal detail of lldap/the ldap-reconciler that never reaches
ClusterMember/ClusterMemberOut.