feat(api): add groups field to password requests and responses

[CasLubbers]

Overview

Adds groups to the gRPC API's Password message and new_groups to UpdatePasswordReq, so local users managed over the API can carry groups. storage.Password.Groups already existed; only the API surface was missing.

What this PR does / why we need it

Groups for local passwords were added in #4456 and work through the config file, but the gRPC API could not set them. A
user created over the API authenticates with no groups, so any relying party that authorizes on the groups claim treats
them as unprivileged. That left the config file as the only way to manage users with groups, which requires a restart to dex to take effect.

• CreatePassword copies groups into storage
• UpdatePassword accepts new_groups and counts it as a change on its own
• ListPasswords returns groups, so the field is not write-only

No storage changes and no migration, the column has existed since #4456.

Closes #4972

Special notes for your reviewer

Groups can be set and replaced, but not cleared. Proto3 encodes an empty repeated field to the same zero bytes as an absent one, so new_groups: [] arrives as nil and reads as "leave alone". This matches every repeated field already in the API, UpdateClientReq treats redirect_uris, trusted_peers, allowed_connectors, sso_shared_with and post_logout_redirect_uris the same way, and none of them can be cleared either. I followed the existing convention rather than making this one field special. If clearing is wanted, it seems better solved once for all six fields, a FieldMask on the request, or a wrapper message per field, and would need a new tag number, since changing tag 4 from repeated string to a message is wire-breaking.

Other notes:

• api.pb.go is regenerated with the pinned toolchain (protoc 29.3, protoc-gen-go 1.36.5); most of the diff is the
  descriptor blob re-wrapping.
• TestPassword now covers groups end to end: set on create, read back via storage and ListPasswords, changed via
  update, and left untouched by an update that does not mention them.
• Verified on a kind cluster with storage.type: kubernetes — groups set over gRPC reach the groups claim in the ID
  token, and a password created without groups omits the key in the CR.