docs: le nommage de NextGraph l'emporte toujours — y compris sur nos propres règles

La règle que je venais d'écrire bannissait « publish » sans réserve. Or le
moteur emploie `publisher` 126 fois — `as_publisher`, `publisher_advert` — pour
un rôle pub/sub sur un topic. Une règle appliquée à la lettre aurait fait
rejeter du vocabulaire amont, ce qui est exactement l'inverse du but.

Le principe est donc posé au-dessus, et il prime sur tout : là où la cible a un
mot, c'est le mot, point. Ce qui reste banni est NOTRE « publier un document »,
qui n'a aucun référent en amont et recouvre trois actes distincts — placer dans
un store public, rendre trouvable, remettre une clé. Ça n'autorise jamais à
renommer ce que l'amont appelle `publisher`.

`publisher`, `topic` et `advert` rejoignent le vocabulaire déclaré du contrôle
de noms, avec la raison en commentaire.

Le renommage `publishRepoLink` → `recordInPublicStore` reste justifié : cette
méthode n'a pas de pendant amont, elle enregistre un document en store public
(et, artefact d'émulation, lui frappe une clé).

packages/client/test/vocabulary.test.ts

@@ -42,6 +42,11 @@ const TARGET_WORDS = new Set([
   "fetch", "init", "watch", "sparql", "ng", "orm", "type", "types",
   // RDF / SPARQL terms the engine's own query paths use
   "subject", "base", "schema", "connected", "identity", "identities",
+  // `publisher` is upstream's word for a pub/sub role on a topic (`as_publisher`,
+  // `publisher_advert`, 126 occurrences in the engine). Our own "publish a document" is
+  // banned as ambiguous, but that ban never reaches upstream's term — see the traps
+  // block in `docs/readcap-and-nuri-model.md`.
+  "publisher", "topic", "advert",
   // the reactive model the ORM exposes (`OrmSubscription`, `DeepSignalSet`)
   "observable", "deep", "signal", "set",
 ]);