test(e2e): le parcours d'un primo-arrivant, et un harnais qui échoue au lieu de se pendre

Aucun parcours n'avait jamais marché le chemin d'un nouvel arrivant : tous
pré-injectaient l'identifiant dans l'URL, ce qui fait résoudre l'identité sans
jamais afficher la barrière. La suite était verte par-dessus un lien de
téléchargement pointant sur un fichier que personne ne servait — et le serveur
de test répondait la page HTML de l'application pour tout chemin inconnu, donc
un fichier manquant ne POUVAIT pas échouer.

Le nouveau parcours part d'un profil vide : barrière, téléchargement réel,
import dans l'application portefeuille, saisie de l'identifiant, remise au
broker, retour dans l'iframe. Il vérifie neuf points, dont celui qui compte —
l'identifiant a survécu et l'identité rapportée est celle qui a été saisie.

Le harnais, lui, se pendait au lieu d'échouer. Cause observée : le tuyau
devtools de Chromium lâche et Playwright n'émet ni close ni disconnected, si
bien que la suite bloquait dans son propre nettoyage sans imprimer ni résumé ni
l'échec déjà en route. Toutes les attentes sont désormais bornées et nomment ce
qu'elles attendaient ; vérifié en cassant délibérément une attente, et observé
en conditions réelles — trois minutes et « gave up waiting for: alice to sign
in » là où j'ai tué trois exécutions d'une heure ce matin.

Deux exécutions simultanées ne se détruisent plus : verrou atomique sur le
profil, et récupération d'un navigateur laissé par une exécution tuée. Le
marqueur devient .user-consumed — il n'a jamais attesté d'une disponibilité,
seulement qu'un lot avait déjà pris l'utilisateur de ce profil. Au passage, la
destruction du profil dépendait du marqueur, écrit en FIN de lot : une
exécution tuée avant laissait un profil que la suivante réutilisait, et
héritait de sa casse. Elle dépend maintenant du profil.

La suite applicative reste non mesurée sur cette machine : un conteneur en
boucle de redémarrage recycle son interface réseau, et sept exécutions sur dix
échouent sur le transport. Trois sont passées 21/21.

packages/polyfill/src/shared-wallet/access-gate.ts

@@ -370,10 +370,11 @@ async function resolveIdentity(): Promise<PrincipalId> {
  * the address bar as it finds it; settling after the hand-over sends the round-trip off
  * without the identifier, which fails silently (see {@link rememberIdentity}). That used to
  * be a rule an application had to follow, and following it hung — so the polyfill's `init()`
- * awaits {@link settleIdentity} itself. This call is safe in any position: after `init()` it
- * finds the identity already set, and alongside it — which is what an application's
- * bootstrap actually does — it JOINS the settling in flight rather than raising a second
- * barrier. Either way it goes on to the connection work, which is what it adds.
+ * awaits {@link settleIdentity} itself. This call is safe FROM `init()` ONWARDS: after it, the identity is
+ * already set; alongside it — what an application's bootstrap actually does — it JOINS the
+ * settling in flight rather than raising a second barrier. It is NOT safe strictly BEFORE
+ * `init()`: the connection work it adds awaits a session only `init()`'s callback resolves,
+ * so awaiting it first deadlocks in silence. Either way it goes on to the connection work, which is what it adds.
  *
  * **It RETURNS the identity it settled**, and that is not a convenience — it is the only
  * way an application can know who it is. Upstream the question does not arise: an app