[Bug Bash] A binding with a trailing space is accepted and silently matches nobody. #3232

A binding with a trailing space is accepted and silently matches nobody. user:system:serviceaccount:bugbash:carol (trailing space) is stored, and the admin sees carol in get access-policy, but no real principal has that ID. Validation should reject leading or trailing whitespace.

Steps, on main (ffed855) on GKE:

cat > p.yaml <<'EOF'
metadata:
  name: default
bindings:
- role: viewer
  members: ["user:system:serviceaccount:bugbash:carol "]
EOF
kubectl ate create access-policy -a team-b -f p.yaml   # accepted
kubectl ate get access-policy -a team-b               # shows carol as viewer
kubectl ate --token-file carol.token get atespace team-b   # denied

FormatMember in cmd/ateapi/internal/authz/authz_util.go rejects an empty or whitespace-only ID, *, and control characters. It doesn't reject leading or trailing spaces. formatUser then encodes the space as %20, so the stored tuple can never match an authenticated principal. The table printer hides the trailing space, so the policy looks correct.

What validation does reject, as checked on the cluster: user:*, user:, group:eng, a bare alice, and IDs over the length limit. It accepts user:a#member, which is safe because # is percent-encoded.

Suggested fix: reject a member whose ID differs from strings.TrimSpace(id), with an InvalidArgument naming the binding. Leading and trailing non-ASCII spaces, such as U+00A0, probably need the same treatment.

Found during the authorization bug bash, with help from an AI agent. I reproduced it on the cluster.