Après connexion, proposer d'ajouter le profil de l'utilisateur

**Tension**
Avec la nouvelle connexion par POD, le profil se trouve sur le POD. Mais par défaut, il est privé.

**Proposition**
Proposition faite après réflexion avec @simonLouvet

Après la connexion, regarder si l'utilisateur a un profil attaché au COD (recherche des profiles avec le webId dans "as:describes")

Si oui, utiliser ce profil pour le menu utilisateur (Voir / éditer mon profil).

Si non, afficher un écran qui lui permet de choisir un profil à ajouter sur le COD:
- Si un profil public existe, il peut le sélectionner directement
- Si un profil privé existe, il peut le rendre public

Il peut aussi créer un nouveau profil, à partir d'un profil existant (fork) ou à partir de rien.
Il peut choisir si créer le profil sur le COD ou sur son POD. L'avantage de créer sur son POD est que le profil peut être réutilisé sur d'autres applications. Dans ce cas l'URI du profil est ajouté (PATCH) au container.

Il peut aussi ne pas se créer de profil. Dans ce cas, il peut naviguer sur le site, profiter des droits WebACL, etc, mais personne ne saura qu'il s'est connecté.

S'il crée un nouveau profil, celui-ci est indiqué dans le prédicat "as:url" de son webId. Il peut donc y en avoir plusieurs et il faudra adapter le code ActivtiyPods pour prendre en compte cette possibilité.

Les relations sont ajoutées à son profil et non à son webId. Cela permet de respecter les règles RGDP, car est considéré comme données personnelles tout ce qui peut potentiellement identifier une personne.

Si le profil du POD est supprimé, il sera aussi détaché du COD par le mécanisme du mirroir (fetch toutes les heures). Cela garantit un fonctionnement optimal RGDP. Il faut veiller à supprimer les relations inverses.

Il faut prévoir un fix pour que les relations inverses soient générées car ce n'est pas le cas pour le moment.

No files, tests, or entry points are named. Start by locating the post-login flow, COD/POD profile lookup, ActivityPods mirror, and inverse-relation handling. Done means the proposed profile selection, creation, attachment, deletion, and relationship behaviors are specified and covered across those flows.

Written by the indexing model from the issue text.