docs(8.0): correct public docs to the real 8.0 API + honest perf claims

The GA-readiness audit found the public docs had drifted from the shipped
surface and presented uncited performance numbers as measured fact.

- quick-start: `FindResult`→`Result`, `VerbType.BuiltOn`→`DependsOn` (the
  canonical getting-started example now compiles).
- noun-verb-taxonomy: rewrote every sample off removed/fictional APIs
  (`augment`/`connectModel`/`getVerbs`/two-arg `add`/`like`/`$gte`) onto the
  real single-object `add`/`find`/`relate`/`related`; replaced the stale
  31-noun/40-verb catalogs with accurate, complete tables (42 nouns, 127 verbs).
- triple-intelligence: `like:`→`query:`, dollar-operators→bare operators, and
  several other fictional keys swept to the real `FindParams`.
- FIND_SYSTEM / PERFORMANCE / index-architecture / BATCHING: replaced
  fabricated, mutually-inconsistent latency tables and uncited speedup
  multipliers with Big-O characterizations, qualitative mechanism descriptions,
  and the one genuinely-measured benchmark (graph O(1) neighbor lookup), per the
  evidence-based-claims rule.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/BATCHING.md

@@ -78,10 +78,10 @@ for (const [id, metadata] of metadataMap) {
 - ✅ Direct O(1) path construction from ID (no type lookup needed!)
 - ✅ Sharding preservation (all paths include `{shard}/{id}`)
 - ✅ Write-cache coherent (read-after-write consistency)
-- ✅ 40x faster than v5.x type-first architecture
+- ✅ O(1) path construction — eliminates the per-entity type search of the old type-first layout
 
 **Performance:**
-- ~1ms per 100 entities (consistent, no cache misses!)
+- Constant-time path construction per ID — no type-cache misses
 - Filesystem: parallel reads bounded by IOPS
 - No type search delays — every ID maps directly to storage path
 
@@ -121,7 +121,7 @@ for (const [sourceId, verbs] of results) {
 - Bulk export of relationship data
 
 **Performance:**
-- Memory storage: <10ms for 1000 relationships
+- Memory storage: single in-memory pass over the metadata index
 - Filesystem storage: parallel reads through the metadata index
 
 ---
@@ -171,7 +171,7 @@ entities/verbs/{SHARD}/{ID}/metadata.json
 
 **Direct O(1) Path Construction:**
 ```typescript
-// Every ID maps directly to exactly ONE path - 40x faster!
+// Every ID maps directly to exactly ONE path - O(1), no type search
 const id = 'abc-123'
 const shard = getShardIdFromUuid(id) // → 'ab' (first 2 hex chars)
 const path = `entities/nouns/${shard}/${id}/metadata.json`
@@ -183,9 +183,9 @@ const path = `entities/nouns/${shard}/${id}/metadata.json`
 ```
 
 **Benefits:**
-- **40x faster** path lookups (eliminates 42-type sequential search)
+- **O(1)** path lookups (eliminates the 42-type sequential search the old type-first layout required)
 - **Simpler code** - removed 500+ lines of type cache complexity
-- **Scalable** - works at billion-scale without type tracking overhead
+- **Scalable** - works at large scale without type tracking overhead
 
 ---
 
@@ -220,28 +220,22 @@ await db.release()
 
 ---
 
-## Performance Benchmarks
+## Why Batching Is Faster
 
-### VFS Operations (12 Files)
+Batching's advantage is structural, not a fixed multiplier (the actual speedup
+depends on storage backend, IOPS, and batch size):
 
-| Storage | Before optimization | After optimization | Improvement |
-|---------|---------------------|--------------------|-------------|
-| **Memory** | 150ms | 50ms | **67% faster** |
-| **Filesystem** | ~500ms | ~80ms | **84% faster** |
+- **N+1 elimination** — N sequential reads collapse into a single parallel pass
+  (`Promise.all` over the batch).
+- **O(1) path construction** — every ID maps directly to one storage path, with
+  no per-type cache lookup.
+- **One metadata round-trip** — relationship batches fetch all sources' metadata
+  in a single pass instead of one query per source.
 
-### Entity Batch Retrieval (100 Entities)
-
-| Storage | Individual Gets | Batch Get | Improvement |
-|---------|-----------------|-----------|-------------|
-| **Memory** | 180ms | 15ms | **92% faster** |
-| **Filesystem** | ~1.2s | ~120ms | **90% faster** |
-
-### Throughput (Entities/Second)
-
-| Storage | Individual | Batch | Improvement |
-|---------|------------|-------|-------------|
-| **Memory** | 556 ent/s | 6667 ent/s | **12x** |
-| **Filesystem** | ~80 ent/s | ~800 ent/s | **10x** |
+The integration test `tests/integration/storage-batch-operations.test.ts`
+exercises batch vs. individual reads and asserts that batch retrieval is not
+slower than the per-entity loop for large batches; it does not pin a specific
+multiplier, since that is hardware- and IOPS-dependent.
 
 ---
 
@@ -306,7 +300,7 @@ const results = await brain.batchGet(ids)
 const entities = Array.from(results.values())
 ```
 
-**Performance Gain:** 10-20x faster on filesystem storage.
+**Performance Gain:** Replaces N sequential reads with a single batched pass — no fixed multiplier, it scales with storage IOPS.
 
 ---
 
@@ -332,7 +326,7 @@ for (const verbs of results.values()) {
 }
 ```
 
-**Performance Gain:** 5-10x faster due to batched metadata fetches.
+**Performance Gain:** One batched metadata fetch instead of one query per source entity.
 
 ---
 
@@ -450,8 +444,8 @@ return await Promise.all(resolvedPaths.map(path => this.read(path)))
 - `storage.getVerbsBySourceBatch(sourceIds, verbType?)` - Batch relationship queries
 
 **Performance Improvements:**
-- VFS operations: 90%+ faster than the naive per-entity loop
-- Entity retrieval: 10-20x throughput improvement
+- VFS operations: single batched pass instead of N sequential reads
+- Entity retrieval: N+1 reads collapsed into one batched pass
 - Zero N+1 query patterns
 
 **Compatibility:**