docs: nommer par la fonction, et n'annoncer qu'un point d'entrée

Deux corrections indépendantes dans la doc vivante, les briefs et décisions
datés restant tels qu'écrits.

P1a et P1b ne disaient rien à personne. Six mois plus tard il aurait fallu lire
le code pour savoir de quoi on parle, et le coût de la recherche se repaie à
chaque lecture. Ils deviennent cap-surface — la forme des capacités, livrée le
2026-07-28 — et cap-enforcement — ce qui reste : le chiffrement par document et
les gardes d'écriture aujourd'hui décoratives. 28 occurrences.

Et api-contract.md se contredisait à quatre lignes d'intervalle : il annonçait
deux points d'entrée en tête, et en bas qu'il n'y en a qu'un depuis la fusion du
2026-08-07. Vérifié dans package.json avant d'écrire — exports mappe exactement
{".": "./src/index.ts"} et src/polyfill.ts n'existe pas.

Ce qui identifie un symbole polyfill-era ne change pas : le bloc marqué dans
src/index.ts et le test de vocabulaire, plus aucun chemin d'import.

docs/simulation.md

@@ -304,7 +304,7 @@ wallet, everything readable) the lib reproduces that with a read-filtered view:
   type would be a concept NextGraph does not have. The stand-in key value is the
   constant `OK` (see the module header): the only question the emulation answers is
   *do I hold this cap or not*, so the value says exactly that and pretends nothing
-  more. P1b, not P1a, is the batch that turns the shape into a protection.
+  more. Cap-enforcement, not cap-surface, is the batch that turns the shape into a protection.
 - **`emulated-verifier/read-filter.ts`** — `makeReadFilteredView` wraps the reactive set in a
   `Proxy`: iteration / `size` / `forEach` keep only items whose `@graph` the
   current holder holds; everything else (`add`, `delete`, `has`, `getById`…) forwards to
@@ -340,7 +340,7 @@ Three ways a cap arrives, and there are no others:
 - **Creation.** `createEntityDoc(id, scope)` writes the cap on the store's emulated
   Store branch (`shim:readCap`) and the creator holds it. The consumer declares
   nothing, and the cap is minted exactly ONCE — the stored value is the held value,
-  which is what keeps this correct when P1b makes the key real.
+  which is what keeps this correct when cap-enforcement makes the key real.
 - **Re-listing.** `listMyEntityDocs(id, scope)` READS those records back. It does not
   recompute anything: that is the whole reason for storing them, and it is what lets
   a **fresh session** read its own documents again with nothing re-declared — the
@@ -418,10 +418,10 @@ registry. And dynamically: the cap lands in Bob's inbox, his client processes it
 the read that was empty yields the content — the held-caps signal re-running it.
 
 That is what real NextGraph does, and it holds **without a line of encryption** —
-which is what makes the P1a (shape) / P1b (enforcement) split honest rather than
+which is what makes the cap-surface (shape) / cap-enforcement (enforcement) split honest rather than
 cosmetic. Proven in `test/cross-user-access.test.ts`.
 
-> **After P1a the shape is right and the isolation is still fake.** The stand-in key
+> **After the cap-surface batch the shape is right and the isolation is still fake.** The stand-in key
 > is a constant, and several read paths (`docs.sparqlQuery`/`sparqlUpdate`, the whole
 > inbox, `store-registry`, `subscribe`, `open-repo`) consult no cap at all — worse,
 > any wallet can reach any document. That is the subject of
@@ -501,7 +501,7 @@ The asymmetry that matters:
   the whole reachability graph. A deposit grants the depositor nothing in return —
   upstream it is an anonymous sealed box.
 - **Reading an inbox is confined to its owner** (`isOwnInbox`, enforced in `read` /
-  `readSynced`, hence in `watch`). Since P1a routes ReadCaps through deposits, an
+  `readSynced`, hence in `watch`). Since the cap-surface batch routes ReadCaps through deposits, an
   unguarded read let anyone who knew an inbox NURI collect the caps addressed to its
   owner — defeating directed sharing. Anonymous owns no inbox and reads none.