Align the cap emulation on NextGraph's model, and confine it to a virtual user

Two batches, verified against nextgraph-rs throughout.

P1a — the capability surface. Reading was an ACL (Map<doc, Set<principal>>),
the exact inversion of key possession. It is now possession: `capFor(nuri)` is
the only question, there is no principal parameter anywhere, and nothing turns
a bare reference into a cap. Sharing is `shareCap(cap, toInbox)`, a Link
deposit; receiving needs no operation. `Nuri` and `ReadCap` are template
literal types, so passing a bare reference where a cap belongs is a compile
error, with runtime guards behind it for JavaScript callers.

The virtual user boundary. Every access function is now confined to the
connected user, through two rules on one criterion (possession), implemented in
two places so a lapse in either is caught by the other: authorization at the
passage points, and "do not even attempt" at the callers. The polyfill's own
machinery moved to physical.ts — unguarded, never exported — which replaced an
exemption list: the machinery no longer gets waved through the guard, it calls
something the guard never saw.

Removed, as emulating capabilities the target does not have:
- discovery.ts and its global index. There is no discovery in NextGraph; you
  follow links. It also pooled user data across wallets.
- the cross-account fan-out (listEntityDocs, resolveReadGraphs, allAccounts,
  loadShim), which was cross-user enumeration by construction.
- resolveInboxAnchor, a single inbox common to every user.

Caps are now stored where NextGraph stores them, and read back rather than
recomputed: AddRepo on the store's Store branch for documents a user creates,
AddLink on its User branch for caps received. Inboxes belong to someone — the
user's own, plus one per document — and connecting a user drains them all;
that is the library's job, not the app's.

Corrections worth recording: a ReadCap is `r:`, not `:k:` (reported by
NextGraph's developer, verified in BlockRef::readcap_nuri); received caps DO
have a register (AddLink), contrary to what this repo's notes claimed; and
"wallet" upstream means keyring — what owns three stores is a user, so the
vocabulary follows.

The cap value is the constant OK: the only question the emulation answers is
whether a cap is held. P1b replaces that one constant with a real key.

After this the shape is right and the isolation is still fake. Nothing here may
be described as anonymous or private.

packages/client/docs/sdk-reference.md

@@ -202,11 +202,18 @@ Data is isolated **per document (repo)**, and each document lives in a **scope**
 | Scope | Read | Write |
 |---|---|---|
 | **Private** | Owner only | Owner only |
-| **Protected** | Owner + explicit grant holders | Owner + permissioned collaborators |
-| **Public** | Everyone (no capability needed) | **Owner only** |
+| **Protected** | Owner + whoever the owner delivered the cap to | Owner + permissioned collaborators |
+| **Public** | Whoever has the URL (the repo link) | **Owner only** |
 
 Consequences a consumer must internalize:
 
+- **Reading is key possession, never an authorization list.** You hold a document's
+  `ReadCap` (`…:r:{cap}`) or you do not read it — there is no "may X read Y?" to ask,
+  here or upstream. A cap-less `did:ng:o:…` **names** a document without granting
+  anything, which is what lets public content point at private content without
+  disclosing it. Caps reach you two ways: creating a document files its own, and
+  someone delivering one to your inbox (`shareCap`). Nothing derives a cap from a
+  bare reference.
 - **Isolation is per-document, not per-store.** Holding a store's cap does **not**
   grant read on the documents it contains — each document has its own ReadCap. Fine-
   grained isolation therefore means **one document per entity**
@@ -263,10 +270,9 @@ from the reactive contract:
    for a **single already-opened document**; it is the per-entity **fan-out** that is
    unfit today.
 
-2. **Inbox and discovery index use polling watchers.** The inbox is emulated
+2. **The inbox uses a polling watcher.** The inbox is emulated
    (`AppRequestCommandV0::InboxPost` has no verifier arm today; no wasm helper seals a
-   deposit), so `inbox.watch` ([`../src/inbox.ts`](../src/inbox.ts)) and
-   `discovery.watchIndex` ([`../src/discovery.ts`](../src/discovery.ts)) **poll** via
+   deposit), so `inbox.watch` ([`../src/inbox.ts`](../src/inbox.ts)) **polls** via
    `setInterval` (default 1s) instead of subscribing. The finished contract is push
    (the broker already routes the inbox natively); these become subscriptions when the
    sealed-inbox path (`inbox_post_link`) lands.