docs: rename the native provider to @soulcraft/cor across public docs and JSDoc

The 3.0 native engine ships as @soulcraft/cor (brainy 8.x <-> cor 3.x are a
version-matched pair); the old @soulcraft/cortex package stays on the 2.x/7.x
line. Public docs and .d.ts-visible comments now name the correct package.
Historical 2.x contract references (e.g. the 2.3.1 read-side fallback) keep
the old name deliberately.

docs/architecture/aggregation.md

@@ -33,7 +33,7 @@
 │             ▼                                            │
 │  ┌──────────────────────┐                                │
 │  │  AggregationProvider │  (optional, registered by      │
-│  │  ├─ incrementalUpdate│   plugin like @soulcraft/cortex)│
+│  │  ├─ incrementalUpdate│   plugin like @soulcraft/cor)   │
 │  │  ├─ rebuildAggregate │                                │
 │  │  ├─ queryAggregate   │                                │
 │  │  └─ serialize/restore│                                │
@@ -135,7 +135,7 @@ M2 is clamped to zero on remove to prevent floating-point drift from producing n
 
 The TypeScript engine uses simple comparison for add operations and marks MIN/MAX as potentially stale on delete (since removing the current min/max value requires a rescan). Stale values are lazily recomputed on the next query.
 
-The Cortex native engine uses a `BTreeMap<OrderedFloat<f64>, u64>` that tracks the exact frequency of every value, providing precise MIN/MAX after any sequence of operations without rescanning.
+The Cor native engine uses a `BTreeMap<OrderedFloat<f64>, u64>` that tracks the exact frequency of every value, providing precise MIN/MAX after any sequence of operations without rescanning.
 
 ### Time Window Bucketing
 

docs/architecture/index-architecture.md

@@ -402,7 +402,7 @@ const DEFAULT_EXCLUDE_FIELDS = [
 
 **Purpose**: O(log n) semantic similarity search using vector embeddings.
 
-The default JS implementation is `JsHnswVectorIndex`; an optional native acceleration package (`@soulcraft/cortex`) can register a higher-performing `VectorIndexProvider` through the plugin system. The public API stays the same either way.
+The default JS implementation is `JsHnswVectorIndex`; an optional native acceleration package (`@soulcraft/cor`) can register a higher-performing `VectorIndexProvider` through the plugin system. The public API stays the same either way.
 
 ### Internal Architecture
 

docs/architecture/multiprocess-storage-mixin.md

@@ -22,7 +22,7 @@ requestFlushOverFilesystem(timeoutMs)
 
 They live on `BaseStorage` as no-op defaults and are overridden on
 `FileSystemStorage` with real implementations. Any adapter extending
-`FileSystemStorage` (e.g. Cortex's `MmapFileSystemStorage`) inherits the
+`FileSystemStorage` (e.g. Cor's `MmapFileSystemStorage`) inherits the
 real ones for free.
 
 This works correctly today. The question is whether the methods *belong*
@@ -83,7 +83,7 @@ Benefits:
 ## The case against doing it now
 
 - Breaking change for any adapter that already overrides these methods.
-  `FileSystemStorage` is the only one in-tree, but Cortex's
+  `FileSystemStorage` is the only one in-tree, but Cor's
   `MmapFileSystemStorage` inherits from it — interface relocation would
   ripple through the plugin ecosystem.
 - The current state works. The real failure modes seen in the field

docs/architecture/overview.md

@@ -48,7 +48,7 @@ Pluggable vector index (`VectorIndexProvider`) for efficient nearest-neighbor se
 - **Configurable recall**: `fast` / `balanced` / `accurate` presets trade recall for latency
 - **Scalable**: Handles millions of vectors per process
 - **Persistent**: Serializable to storage
-- **Swappable**: Replace with a native implementation (such as `@soulcraft/cortex`) via the plugin system without changing application code
+- **Swappable**: Replace with a native implementation (such as `@soulcraft/cor`) via the plugin system without changing application code
 
 ### Metadata Index Manager
 High-performance field indexing system:

docs/architecture/zero-config.md

@@ -84,7 +84,7 @@ const brain = new Brainy({
 ```
 
 The default JS index is `JsHnswVectorIndex`. An optional native acceleration
-provider (the `@soulcraft/cortex` package) can replace it with a
+provider (the `@soulcraft/cor` package) can replace it with a
 higher-performing implementation; the public knobs stay the same. Quantization
 and other index-internal acceleration are the native provider's concern, not a
 Brainy configuration option.