fix(group-members): apply custom roles to group shares - #1373

Summary

• honor member_role for groups configured under group_members.groups
• keep group-share updates idempotent by comparing the current member_role_id
• document custom roles on group invitations and add unit/Ultimate acceptance coverage

Root cause

GroupMembersProcessor._process_groups() only considered group access and
expiration. It never resolved the configured custom role, and
python-gitlab's high-level Group.share() method does not currently include
member_role_id in the request body.

Changes

• resolve a configured member role by name or ID through the existing cached
  member-role lookup
• use python-gitlab's lower-level HTTP API only when a custom role must be sent
• include member_role_id in the equality check so unchanged shares are not
  removed and recreated
• restore a regular share when member_role is removed from configuration
• add regression tests and update the member configuration examples

Validation

• .venv/bin/python -m pytest tests/unit — 242 passed
• UV_CACHE_DIR=/private/tmp/gitlabform-uv-cache uv run --no-sync qa lint — passed
• UV_CACHE_DIR=/private/tmp/gitlabform-uv-cache uv run --no-sync docs build — passed
• UV_CACHE_DIR=/private/tmp/gitlabform-uv-cache uv run --no-sync package build — passed
• UV_CACHE_DIR=/private/tmp/gitlabform-uv-cache uv run --no-sync package verify — passed
• tests/acceptance/ultimate/test_group_members.py — collection passed; runtime
  requires a disposable GitLab Ultimate instance and was not available locally

Compatibility and risk

Existing configurations without group_members.groups.*.member_role keep the
same behavior. No migration is required.

When the configured role differs, GitLabForm follows the processor's existing
update strategy of removing and recreating the group invitation. This may
create a brief access gap, but avoids repeated changes once the configured
state is applied.

Closes #1370