fix: readUnion regroupe par sujet réel — la fusion était une divergence

`readUnion` indexait par DOCUMENT une table nommée `bySubject`, créait ses entrées avec
`subject: doc`, et jetait le sujet réellement lu après s'en être servi pour écarter la
machinerie. Tout triplet non-machinerie d'un document tombait donc dans un sac unique
étiqueté par la référence du document : deux entités écrites sous deux sujets revenaient
**conflées**, une entité écrite sous un autre sujet revenait **ré-étiquetée**. Sans erreur,
sans trace.

**C'était une divergence, et c'est à ce titre qu'elle tombe.** NextGraph dit l'inverse aux
deux niveaux : une requête ancrée résout le graphe du repo comme graphe par défaut et rend
les sujets tels qu'ils sont ; et l'ORM porte sur chaque objet **deux** propriétés
distinctes, `@id` et `@graph`, dont il FABRIQUE la première quand on la laisse vide
(`graphIri + ":q:" + aléa`). Plusieurs objets par graphe est le cas prévu, et `@id` existe
pour les distinguer à l'intérieur d'un `@graph`.

La règle du projet reste **« un document séparé par entité métier »**, mais c'est une
recommandation de placement dictée par le modèle de sécurité — une clé est par repo, donc
l'isolation par entité exige un repo par entité. Ce n'est pas une contrainte que la lecture
a le droit d'imposer en rendant l'autre disposition invisible. Le contrat porte désormais la
recommandation, le code porte la capacité ; il faisait exactement l'inverse.

**La justification de l'épinglage était une erreur de catégorie**, et elle a été retirée
plutôt que contournée : `repo_graph_name` formate un nom de GRAPHE, il est estampillé sur
les quads et aucun sujet n'est réécrit. Deux confirmations indépendantes, dont la suite e2e
qui écrit un sujet puis le relit par correspondance exacte contre le vrai broker.

`UnionSubject.subject` passe de `Nuri` à `string` — un sujet RDF réel est un IRI
quelconque. `graph` reste `Nuri` et devient le champ à repasser au SDK ; l'app d'exemple
l'utilise à ses deux sites, où le sens était « le document ».

**Et la suite e2e ne comptait que les entrées.** C'est pour cela qu'elle est restée verte
pendant tout le défaut : compter ne distingue pas un regroupement par document d'un
regroupement par sujet. Elle écrit maintenant deux sujets dans le dernier document et
vérifie les trois choses qui comptent — quatre entrées pour trois documents, chaque entrée
portant le sujet sous lequel elle a été écrite, et son `graph` étant la référence du
document.

202 tests unitaires (5 ajoutés, dont 3 échouent si l'on restaure l'ancien repliage),
e2e 42/42 et applicatif 12/12.

packages/sdk/e2e/sdk-entry.ts

@@ -345,9 +345,27 @@ const identity = new IdentityStore(
       );
       docNuris.push(d);
     }
+    // Two SUBJECTS in the LAST document, so the probe can tell "one entry per document"
+    // from "one entry per subject". Until 2026-08-10 `readUnion` folded every triple of a
+    // document into one bag keyed by the document, and this step stayed green throughout
+    // because it only ever counted entries and never looked at what they were.
+    if (n > 0) {
+      await docs.sparqlUpdate(
+        s.session_id,
+        `INSERT DATA { <urn:e2e:rm:extra> <urn:e2e:idx> "extra" }`,
+        docNuris[n - 1]!,
+      );
+    }
     const toRead: Nuri[] = includeBad ? [...docNuris, "did:ng:o:definitely-not-a-real-doc-xyz"] : docNuris;
     const subjects = await readUnion(toRead);
-    return { docNuris, subjectCount: subjects.length, subjects };
+    return {
+      docNuris,
+      subjectCount: subjects.length,
+      // What each entry actually IS — the assertion the count could not make.
+      subjectIris: subjects.map((x) => x.subject),
+      graphs: subjects.map((x) => x.graph),
+      subjects,
+    };
   },
   /**
    * readUnion possession gate: create a doc as owner O (whose keyring gets its