Implement frontend UI for group membership management

[robertknight]

Implement the UI for managing group members in the new group forms.

See discussion in https://hypothes-is.slack.com/archives/C1M8NH76X/p1730388739712579. The Figma designs are in the "Flows" page in https://www.figma.com/design/jon1U01LGSLcx7PWtZ9TPZ/Hypothesis---Group-Management?node-id=2584-77&node-type=canvas&t=OULpVFk8bte1XWnZ-0.

[seanh]

I think all the necessary backend work for the group-membership-management MVP is now merged and deployed to production, so the frontend should be unblocked to complete the feature now. In particular:

• js_config["context"]["user"]["userid"] is the userid of the authenticated user, which for now should be used to make sure that the authenticated user's own row in the membership table isn't editable (neither to change your own role, nor to remove yourself from the gruop).

  @robertknight: note that I renamed this to "user" and also moved it inside the "context" object.

  The intention is that in future the user's own row will become editable but editing it will trigger a different UX so js_config["context"]["user"]["userid"] will still be needed. Making the user's own row editable should wait until after pagination has been implemented.

• The readGroupMembers API's responses now include information about each member's current role and about the actions that the authenticated user can take against each member.

  Note that roles is an array of role strings not a single role string, but (for now) it's always an array of length 1 (this is enforced by the backend by both request validation and DB constraint). It was done like this in case we want to have multiple roles in future.

• The readGroupMembers API returns the members in the order that we want them to be displayed in: alphabetically by username. (There's a future issue to change this default sort order to be by joined date, but the backend doesn't currently record joined dates in the DB.)

• There's a new DELETE API for removing a member.

• There's a new PATCH API for editing a member's role.

  Note that after calling this API the frontend needs to re-render the edited member's row in the table: their role may have changed, and also the actions that the authenticated user can take against them may have changed. The response body from the PATCH API will contain the updated membership in the same format as from the readGroupMembers API including the new role and actions. The frontend should use this response body to update the table row.

  Gotcha: the response body may also contain a different display_name if the user has changed their display_name since the page loaded. The frontend may not want to update the display name field in the rendered table, since it might be confusing to the user if a member's name changes while they're using the table.

  Known issue: unfortunately Hypothesis users don't have any immutable, public, unique identifiers. A user's userid changes if they change their username. This means that if a group admin loads the group membership management page, then a member changes their username, then (without reloading the page) the group admin tries to change that member's role or remove that member from the group, the API will request will 404. I don't think there's any quick fix to this without adding persistent public user IDs.

• The new PATCH and DELETE APIs have been added to js-config with :userid in place of the user ID in the URL.

• The new PATCH and DELETE APIs have been added to the list of APIs that cookie-and-CSRF-token-authenticated requests can be made to.

@robertknight @acelaya Please remove the search box and the count of the number of members from the Edit group page. Dan has clarified that we're not going to be adding these and other additional features to the page: the minimal page will be sufficient, and it's going to be higher priority to move on to other projects. But I am planning to add pagination to the page, and the presence of the search box and members count would make adding pagination take longer because both would need to be re-implemented in pagination-compatible ways.