refactor: les commentaires disent cap-surface et cap-enforcement

Suite du balayage commencé dans la doc : 20 occurrences de P1a/P1b dans les
commentaires, les titres de tests et le README.

Les phrases ont été récrites, pas substituées : « the breach P1a opened »
devient « the breach that cap-surface opened », et « labelled P1b's » ne
survivait pas à un nom plus long. Un lecteur qui n'a jamais entendu ni l'un ni
l'autre doit comprendre la phrase.

L'avertissement de déploiement du README garde sa force et gagne un nom :
« "anonymous" or "private" until cap-enforcement lands per-document
encryption. »

Reste une occurrence dans e2e/polyfill-entry.ts, qui part avec le lot e2e.

packages/polyfill/test/caps.test.ts

@@ -2,7 +2,7 @@
  * caps.test.ts — the cap surface as KEY POSSESSION.
  *
  * What these prove is a SHAPE, not a protection (the library is deliberately
- * insecure until P1b): the only question the registry can answer is "do I hold
+ * insecure until cap-enforcement): the only question the registry can answer is "do I hold
  * this document's cap?", there is no principal to look up in a list, and no
  * function turns a bare reference into a cap.
  */
@@ -170,7 +170,7 @@ test("a cap arriving fires the change signal — an asynchronous delivery must r
   expect(fired).toBe(1); // unsubscribed
 });
 
-test("write is restricted to write-cap holders (decorative until P1b)", () => {
+test("write is restricted to write-cap holders (decorative until cap-enforcement)", () => {
   const { caps } = registry();
   expect(caps.hasWritePolicy()).toBe(false);
   caps.grantWrite("did:ng:o:doc", "alice");