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/bdd-testing/_debt.md

@@ -1,12 +0,0 @@
-# Doc-debt — bdd-testing
-
-> 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/shared/test-harness/harness-ng.tsx @2026-07-05 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
-- TOUCHED src/modules/workshop/features/read-model-probe.feature @2026-07-05 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
-- TOUCHED src/modules/workshop/steps/data/read-model-probe.steps.ts @2026-07-05 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
-- TOUCHED src/modules/event/steps/data/inscription.steps.ts @2026-07-05 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
-- TOUCHED src/shared/support/hooks.ts @2026-07-06 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
-- TOUCHED src/modules/auth/steps/data/connexion.steps.ts @2026-07-06 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)

.project/concepts/bdd-testing/caveat_wallet-bloat-hang.md

@@ -0,0 +1,35 @@
+---
+type: caveat
+summary: Le wallet de test partagé (.playwright-profile) accumule des données à chaque run ; passé un seuil, les sparql_query ancrées au private store hangent (>15s) et toute la suite @data échoue au setup — repartir d'un profil frais restaure des lectures ~1s
+last_checked: 2026-07-06
+---
+
+# Piège : le wallet de test se gonfle et fait *hang* les lectures @data
+
+Le profil Chromium persistant `.playwright-profile` (racine du working tree) porte le **wallet
+partagé** ouvert par toute la suite `@data`/`@e2e`. Ce wallet **accumule des données à chaque
+run** : comptes shim (un par scénario, via l'identifiant frais `freshScenarioUsername`), docs
+d'entités seedés, dépôts d'inbox historiques… Le private store est le **point d'ancrage du shim**
+(résolution de compte) et est interrogé par **toute** lecture/écriture (`resolveAccount`,
+`listMyEntityDocs`, …).
+
+**Symptôme.** Passé un certain volume (observé ~99 Mo de profil), une `sparql_query` **ancrée au
+private store** ne revient plus sous 15 s — elle *hang*. Comme la résolution de compte est sur le
+chemin de **chaque** read/write, **toute la suite @data échoue au setup** (0 événement chargé,
+timeouts), sans erreur explicite. Diagnostic vérifié : sur un wallet frais la même requête revient
+en **~1,5 s** et le seed complète normalement.
+
+**Contournement.** Mettre le profil gonflé de côté et laisser le hook d'auth (beforeAll) en
+recréer un frais :
+
+```bash
+mv .playwright-profile /tmp/festipod-bloated-$(date +%s)
+```
+
+L'identifiant frais par scénario (`freshScenarioUsername`) borne le *registre* des comptes mais
+**pas** la croissance physique du private store partagé — d'où la récurrence. Une hygiène durable
+(purge périodique / wallet jetable par run) reste à mettre en place ; en attendant, si les
+`resolveAccount failed`/timeouts réapparaissent, repartir d'un profil frais.
+
+> Le *pourquoi* côté broker (comment une requête ancrée touche le repo du private store) appartient
+> au SDK `@ng-eventually/client`, pas ici — ce caveat ne décrit que la conséquence côté tests.