Removing a member from a disabled project or group fails with not found #2051

What happens

Removing a user from a disabled project or a disabled group fails with not found. Changing their role there fails the same way. To take someone's access away, an admin first has to enable the project or group, remove the member, and disable it again.

Why

The membership calls load the project or group first, and that lookup skips disabled rows:

• SetProjectMemberRole and RemoveProjectMember call projectService.Get (core/membership/project.go:19, :64).
• SetGroupMemberRole and RemoveGroupMember call groupService.Get (core/membership/group.go:35, :112).
• ProjectRepository.GetByID and GroupRepository.GetByID filter out disabled rows (internal/store/postgres/project_repository.go:62, internal/store/postgres/group_repository.go:36), so the lookup returns not found.

Why it matters

A disabled project or group keeps its members' policies and SpiceDB relations. When it is enabled again, everyone still listed gets their access back. It should be possible to remove a member before that, without enabling it first.

Removing a member from the whole organization already covers disabled projects and groups (#2049).

Proposed fix

Load the project or group including disabled ones when removing a member, the way the deleter already lists them (IncludeDisabled: true). Decide separately whether adding a member or changing a role on a disabled project or group should stay refused.