fix(server-nestjs): make Registry create paths idempotent

[shikanime]

Issues liées

#2620 (fermer délibérément après la fusion)

---

Quel est le comportement actuel ?

Lors d'une synchronisation concurrente (cron + événement), deux appels peuvent tenter de créer la même ressource Harbor en parallèle. Le POST perdant reçoit une erreur 409 (conflit) et la synchronisation échoue avec une erreur.

Quatre chemins de création sont concernés : la création de projet, l'ajout d'un membre de groupe, la création d'un robot et la création d'une stratégie de rétention. Chacun était protégé par un GET d'existence préalable dans la couche métier, mais sous une course cette garde ne suffisait pas.

Comportement attendu

L'idempotence est encapsulée dans le service client (registry-client.service.ts) sous un motif ensure* create-first : on tente la création ; si la ressource existe déjà (409), on la met à jour puis on relit l'état courant. La synchronisation devient idempotente face à la course.

Changements

• registry-client.service.ts expose ensureProject, ensureGroupMember, ensureRobot et ensureRetention : chaque méthode tente la création, puis réconcilie sur un 409.
• Création de projet : un 409 est toléré, la ressource est relue puis retournée.
• Ajout de membre de groupe : un 409 est ignoré, le membre existe désormais.
• Création de robot : un 409 renvoie null, la couche métier déclenche une rotation pour obtenir un secret frais.
• Stratégie de rétention : un 409 déclenche une relecture puis une mise à jour.
• La couche métier (registry.service.ts) est simplifiée : elle appelle les méthodes ensure* et ne gère plus les statuts 409 elle-même.
• Ajout de tests unitaires (client et service) couvrant les collisions sur la création de projet, de robot et le retour de l'existant.