fix(client): per-entity write round-trip + dedicated inbox anchor

Real-broker validation of the per-document model surfaced round-trip breaks the
fake-ng unit tests missed:
- The inbox anchor was the shim graph itself, making loadShim ~60s; give the
  inbox its own document so anchor resolution is fast and isolated.
- store-registry adjustments so per-entity documents created via the SDK are
  indexed and readable back through the scope fan-out.
docs/simulation.md updated. 89 tests pass; tsc rc=0.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/simulation.md

@@ -96,9 +96,15 @@ store-id:
   blocker, [`migration-guide.md`](./migration-guide.md)). At migration each scope
   resolves to the user's REAL per-scope store — the change is in this function,
   the consumer is unchanged.
-- **`resolveInboxAnchor()`** — the anchor where emulated inbox deposits land
-  (today the shared wallet's private store — a real repo NURI, required because
-  the broker rejects a `urn:` anchor). At migration it becomes the host's native
+- **`resolveInboxAnchor()`** — the anchor where emulated inbox deposits land: a
+  **DEDICATED inbox document** (a reserved account's public scope document, from
+  `docCreate` — a real repo NURI, stable across clients), **not** the shared
+  wallet's private-store root. Why dedicated: the shim (the account→document trust
+  root) lives in the private-store graph and is scanned on every `loadShim`;
+  routing every inbox deposit into that SAME graph bloats it without bound
+  (thousands of deposit triples across sessions), turning `loadShim` into a
+  multi-second full-graph scan. A separate inbox document keeps the shim graph
+  small and the deposits isolated. At migration it becomes the host's native
   inbox NURI.
 
 Both resolve the native store ids from the **injected session**