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/isolation-active.test.ts

@@ -341,7 +341,7 @@ test("one held caps per virtual WALLET, not per spelling of its id", async () =>
   expect(hasCap(doc)).toBe(false);
 });
 
-// THE BREACH P1a OPENED. Caps travel as inbox deposits, so an unguarded inbox read
+// THE BREACH THAT cap-surface OPENED. Caps travel as inbox deposits, so an unguarded inbox read
 // let anyone who knew an inbox NURI collect the caps addressed to its owner —
 // defeating directed sharing entirely. Depositing stays open (it is the only way a
 // link crosses between wallets at all); reading does not.
@@ -393,7 +393,7 @@ test("a fresh session rebuilds the held caps from the scope index (the emulated
 // The Store branch exists so a cap is READ back, not recomputed. Without this test
 // the two are indistinguishable: with a stand-in value, re-minting happens to give
 // the same string. So corrupt the stored cap and check the corruption wins — proof
-// the value comes from the store, and proof that P1b's real key will too.
+// the value comes from the store, and proof that cap-enforcement's real key will too.
 test("a document's cap is READ from the Store branch, never recomputed", async () => {
   const ng = inject();
   setCurrentUser("alice");
@@ -426,7 +426,7 @@ test("the listing and the caps are two separate records", async () => {
   expect(subjects.has("urn:ng-eventually:shim:storeBranch")).toBe(true); // Store branch: readCap
 });
 
-// P1b will make the stand-in value a real, non-derivable key. The moment it does,
+// cap-enforcement will make the stand-in value a real, non-derivable key. The moment it does,
 // any path that mints a SECOND cap instead of using the stored one breaks: the
 // creator would hold a key that does not open its own document. This pins that the
 // creation path mints exactly once.