Manage domain membership (users & teams) from the Domain page for mesh governance

[AntoineGlacet]

Is your feature request related to a problem? Please describe.

Users and teams can be assigned to a domain today, but only from the User and Team pages (user.domains / team.domains), and only by admins — patching those fields requires EditAll on each user/team.

For data-mesh governance this is backwards: a domain owner should be able to manage, from the domain page, which users and teams belong to their domain. Combined with the built-in hasDomain() policy condition and DomainOnlyAccessRole, domain membership is what controls who can see the domain's assets — so the domain owner should own that list, by groups of assets (the domain), not asset by asset. Today the only workarounds are admin-driven per-user edits or custom properties, neither of which scales.

Describe the solution you'd like

1. Domain-side membership API, following the existing PUT /v1/domains/{name}/assets/add|remove precedent:

   • PUT /v1/domains/{name}/members/add and PUT /v1/domains/{name}/members/remove accepting mixed user/team entity references (BulkAssets payload, dryRun supported).
   • Authorized by EditAll on the domain, so domain owners (via the default owner policy rule) and admins can manage membership — no change to the User/Team page behavior.
   • Writes the same Domain --HAS--> User/Team relationship rows that user.domains / team.domains are read from, so both sides stay consistent by construction. Adding/removing must touch only that one domain relationship (users/teams can belong to multiple domains).

2. "Users & Teams" widget on the Domain page (Documentation tab right panel, alongside Owners/Experts/Domain Type, registered in the customizable page layout):

   • Lists all users and teams assigned to the domain (search-backed via domains.fullyQualifiedName on the user/team indexes).
   • Team-inherited user memberships are displayed with the inherited icon and are not removable from the domain (removal belongs on the team).
   • Edit affordance (gated by the domain EditAll permission) opens the standard Users/Teams picker — including teams of all types, not just Group.

Describe alternatives you've considered

• Frontend-only (widget PATCHes each user/team like the User page does): no backend change, but stays admin-only and defeats the domain-owner governance goal.
• A granular EditDomains operation on user/team resources: policy-driven but not scoped per domain — a grantee could edit anyone's membership to any domain.
• users/teams entity fields on Domain edited via PATCH: the codebase deliberately deprecated domain.assets as an entity field (scale, version bloat) in favor of bulk endpoints + search listing; membership has the same shape.
• Data products as the container: rejected — there is no user.dataProducts assignment and the policy engine has no data-product condition; domains (and subdomains, since hasDomain() matches hierarchically) are the platform-native access boundary.

Additional context

I have a working implementation (backend endpoints + repository methods + integration tests, UI widget + unit tests, verified end-to-end with Playwright against a local stack) and will open a PR linked to this issue.