feat(auth)+refactor(app): identifier at the access barrier; adopt the lib fidelity refactor

Consumer-side of the @ng-eventually/client fidelity pass, plus the identifier UX:

- Identity: the user types an IDENTIFIER at the access barrier (AccessGateScreen),
  in the same act that opens the shared wallet — the separate 'pick a username'
  screen (ConnexionScreen) is removed. The identifier is a technical id (a pseudo
  in practice, not a Festipod username), normalized (trim, @-stripped, lowercased)
  and persisted before the broker redirect, then handed to the SDK as the identity.
  AccountContext keeps its API but its stored value is now this normalized id.
- Relationship/connections are app-owned: new src/shared/utils/connections.ts holds
  the bilateral registry and maps each link to the SDK's directed grantRead(doc,
  grantee); the lib no longer carries a connection concept. Rewired FestipodData
  and the @data harness to it.
- Login removed: accounts use the SDK's IdentityStore (set/clear/get); no faux
  login/logout framing in the SDK boundary.

Doctrine reconciled: app-security (knowledge_authentication flow, knowledge_trust-model
directed grants, decision_2026-07-06_identifier-at-access-barrier), data-layer
(knowledge_context-internals: stable id principal + single-seed), app-architecture
(knowledge_screens auth inventory), bdd-testing (caveat_wallet-bloat-hang).

App gates: tsc no new errors, build OK. @data path unaffected (harness bypasses the
gate and sets identity directly; login() is not on that path).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.project/concepts/app-security/_debt.md

@@ -1,7 +0,0 @@
-# Doc-debt — app-security
-
-> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
-> One block = one "big change": `why` + `files` + `verify` (leaves to review).
-
-## Raw markers (consolidate into blocks, then delete)
-- TOUCHED src/modules/auth/steps/data/connexion.steps.ts @2026-07-06 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)

.project/concepts/app-security/decision_2026-07-06_identifier-at-access-barrier.md

@@ -0,0 +1,45 @@
+---
+type: decision
+summary: L'identifiant de l'espace virtuel se saisit à la barrière d'accès (AccessGateScreen), dans le même acte que l'ouverture du wallet ; l'écran de « login perçu » séparé (ConnexionScreen, « choisissez un nom d'utilisateur ») est retiré ; l'identifiant est un id technique normalisé en minuscules, pas un username Festipod
+---
+
+# Décision (2026-07-06) : identifiant saisi à la barrière d'accès
+
+## Contexte
+
+Le flux stopgap de [[decision_2026-06-15_shared-wallet-login-flow]] enchaînait **deux
+écrans** : (1) `AccessGateScreen`, la barrière d'accès (vrai login NextGraph, ouverture du
+wallet partagé) ; (2) `ConnexionScreen`, un « login perçu » où l'utilisateur choisissait un
+**nom d'utilisateur**. Cette identité applicative était en réalité la clé du **wallet virtuel**
+(clé du compte shim / cap owner), pas un username produit — le cadrage « nom d'utilisateur »
+était donc trompeur (logique `setUsername` confuse).
+
+## Décision
+
+L'utilisateur saisit son **identifiant** directement dans `AccessGateScreen`, **dans le même
+acte** qui ouvre le wallet (« Entrer » enregistre l'identifiant puis déclenche `connect()`).
+`ConnexionScreen` est **supprimé**. L'identifiant :
+
+- est un **id technique** qui nomme l'espace virtuel (un pseudo en pratique, **pas** un
+  username Festipod) ;
+- est **normalisé** à la saisie (trim, `@` retiré, **minuscules**) et persisté avant la
+  redirection broker (donc il survit au round-trip) ;
+- **est** l'id d'identité remis au SDK (`setCurrentUser`), et la clé des caps et du compte
+  shim — plus de handle à casse mixte à réconcilier.
+
+`AuthGate` affiche donc la barrière tant que le wallet n'est pas ouvert **ou** que l'identifiant
+n'est pas posé, puis l'app directement — sans écran intermédiaire.
+
+## Alternatives écartées
+
+- **Garder les deux écrans** : le second écran « nom d'utilisateur » perpétuait la confusion
+  entre identité-produit et identifiant-de-wallet, et ajoutait une étape sans valeur.
+- **Dériver l'identifiant du wallet** (pas de saisie) : impossible ici — le wallet partagé est
+  unique ; l'identifiant est précisément ce qui distingue les espaces virtuels au sein de ce
+  wallet (émulation, cf. concept `data-layer` et le SDK `@ng-eventually/client`).
+
+## Portée
+
+Supersede la partie « écran 2 / login perçu » de [[decision_2026-06-15_shared-wallet-login-flow]]
+(l'ouverture du wallet partagé via broker reste inchangée). État courant du flux :
+[[knowledge_authentication]].

.project/concepts/app-security/knowledge_authentication.md

@@ -9,7 +9,8 @@ summary: L'identité d'un utilisateur = son wallet NextGraph ; tous les utilisat
 
 ## Flux
 
-- L'écran d'auth (`src/modules/auth/`) déclenche la connexion via `useNextGraph()` (ne consomme pas `useFestipodData`).
+- La **barrière d'accès** (`AccessGateScreen`, rendue par `src/app/AuthGate.tsx`) est le vrai login NextGraph : elle ouvre le wallet partagé via la redirection broker. **Dans le même acte**, l'utilisateur saisit un **identifiant** qui nomme son espace virtuel (`onEnter`). Il n'y a **plus d'écran « login perçu » séparé** (l'ancien `ConnexionScreen` « choisissez un nom d'utilisateur » a été retiré — cf. [[decision_2026-07-06_identifier-at-access-barrier]] ; supersede le flux à deux écrans de [[decision_2026-06-15_shared-wallet-login-flow]]).
+- Cet **identifiant est un id technique** (un pseudo en pratique, **pas** un username Festipod) : il est **normalisé** (trim, `@` retiré, **minuscules**) puis persisté (`AccountContext` → `IdentityStore`), donc un rechargement — ou un autre appareil rouvrant le même wallet partagé — retombe sur le même espace. C'est cet id qui est donné au SDK (`setCurrentUser`) et sur lequel les caps et le compte shim sont clés.
 - Une fois la session ouverte, l'utilisateur courant et son accès aux stores par scope sont fournis par `NextGraphContext`.
 
 ## Le wallet de test

.project/concepts/app-security/knowledge_trust-model.md

@@ -1,7 +1,7 @@
 ---
 type: knowledge
 summary: L'isolation entre périmètres (public/protected/private) est assurée par le SDK de données ; l'app lui fait confiance et n'affiche que ce qu'il retourne — aucun contrôle d'accès dans les écrans, toute la confidentialité repose sur le SDK
-last_checked: 2026-07-03
+last_checked: 2026-07-06
 ---
 
 # Modèle de confiance
@@ -12,6 +12,7 @@ Principes :
 
 1. **L'isolation est déléguée au SDK.** Chaque entité vit dans le store de son **scope** (public / protected / private, cf. concept `functional-domain` → [[knowledge_data-scopes-and-discovery]]) ; le SDK **n'expose à l'utilisateur courant que ce à quoi il a droit**. L'app suppose que ce qu'elle reçoit est déjà autorisé — la confidentialité repose sur le SDK, pas sur du code Festipod.
 2. **Les écrans ne portent aucune règle d'accès.** Pas de vérification « cet utilisateur a-t-il le droit de voir cette donnée » dans les composants ni dans le contexte de données. La séparation public / réseau / privé est une propriété du **placement par scope**, pas d'un filtre applicatif.
+3. **La relation entre utilisateurs (« connexions ») est une notion applicative, pas une primitive du SDK.** NextGraph n'a pas de primitive de connexion/amitié bilatérale ; côté SDK il n'existe qu'un **grant de lecture dirigé** vers une identité. L'app **possède** donc son graphe de relations (`src/shared/utils/connections.ts`) et le **traduit** en grants dirigés par document remis au SDK — elle ne délègue pas la notion de relation au SDK, seulement l'**application** de l'isolation qui en découle. Ce que l'app déclare au SDK reste minimal : **son identité** (l'identifiant, cf. [[knowledge_authentication]]) et **ces grants** ; elle ne porte toujours aucune logique d'accès dans les écrans.
 
 ## Le point de vigilance