Frontend WAC group management

**Description**
Thanks to @nikoPLP's work, we have everything we need on the middleware side to create ACL groups, add users to them, and use them for resource or container permissions. But there's nothing yet on the front end (Archipelago, but not only) to use these functionalities.

For group management, after discussion with @simonLouvet, the simplest thing would be to link it to existing groups, so there's no need to create a specific interface for ACL groups. It would also be more functional for the user. For Archipelago, we could automatically create ACL groups for each `pair:Group` or `pair:Project` (for `pair:Organization` it would be more complicated as we use reified relations... there would potentially be several groups per organization). Of course, it would have to be possible to use other ontologies. In terms of middleware, we'd need a bot (inspired by [GroupManagerBot](https://semapps.org/docs/middleware/webacl/groups-manager)) to create groups automatically. It would have to indicate:

- the class(es) (`rdf:type`) of the resources concerned
- The predicate used to link the group with users (WebID)
- The label predicate used for the ACL group title (this should be a function to make it more customizable)

The current superadmin group could be managed in this way. We'd just have to make sure that only a superadmin can modify the list of members of this group (this is possible with permissions, but perhaps it should be configured by default?). This would also require the management of “default” type rights (which have repercussions on child containers and resources), which will require adaptation of the current interface.

There's one last problem: currently, the inference service creates inverse relationships with a `webId: system`. This ignores ACL rights and allows anyone to add themselves to an ACL group of their choice (via Postman). Either the inference service would have to use the rights of the user who made the initial addition (but if the addition of the reverse relationship fails, should the initial relationship be deleted?), or we could specify types of relationships/classes for which we don't want inference.

**Related files**
- [ ] Modal permissions: search ACL groups
- [ ] Modale permissions: display ACL groups linked to the resource and their rights
- [ ] Modale permissions: display permissions inherited from parent containers (cannot be modified)
- [ ] Modale permissions: add default permissions for containers (which apply to children)
- [ ] Modal permissions: add a user/group URL directly (optional, but useful)
- [ ] Middleware: bot that automatically creates ACL groups mirroring existing groups (pair:Group, pair:Project...)
- [ ] InferenceService: exclude predicates/classes from automatic inverse relation generation

Start by reviewing the permissions modals, the middleware GroupManagerBot reference, and InferenceService, then map each related-file checklist item to its current implementation. Done means the frontend can manage linked ACL groups and inherited or default permissions, middleware can mirror configured groups, and inverse-relation handling respects the stated ACL constraints.

Written by the indexing model from the issue text.