La restauration orpheline les liens relationnels sur compte / hôte neuf

[aliceout]

Problème

Les liens relationnels stockent des ids d'enregistrement serveur :

• Habits : chaque log référence son habitude via itemRid (= id serveur).
• Library : chaque avis référence son livre via review.itemRid.

À l'import / restauration sur un autre compte ou un hébergement neuf, les enregistrements reçoivent de nouveaux ids serveur → tous ces liens pointent dans le vide (cf. docs/Architecture.md §7). La sauvegarde .age existe et fonctionne, mais le restore n'est fidèle qu'en même-compte.

Impact

Pour une app dont la promesse est « tes données, pour toujours, tu héberges », un backup qui ne survit pas à une migration d'hôte est un piège silencieux : la restauration paraît réussir, mais Habits perd son historique de complétion et Library ses avis.

Proposition

Une clé stable, indépendante de l'id serveur, portée dans le payload chiffré :

• un clientId aléatoire forgé à la création de chaque enregistrement (le plus propre — pas de collision), ou
• une clé de contenu (hash titre + date) avec gestion de collision (rename / doublons).

À l'import : reconstruire une map ancienId → nouvelId et réécrire les références (itemRid…). Le plugin d'import a déjà getNaturalKey / normalizePayload comme point d'accroche.

Note de conception

Habits et Library sont les jumeaux structurels (même faille) — concevoir la solution conjointement, pas spécifique à un module. Prévoir un backfill pour les données existantes (anciens enregistrements sans clé) ou un double-clé transitoire.

Critères d'acceptation

• Clé stable indépendante de l'id serveur sur les enregistrements concernés (Habits items, Library items)
• L'import re-mappe les références relationnelles
• Backfill des données existantes
• Test e2e : export → import sur compte vierge → liens Habits (log↔habitude) et Library (avis↔livre) intacts