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/concepts/multi-process.md

@@ -55,20 +55,20 @@ process opening the same directory:
 The fix is the lock: refuse to open a second writer. SQLite has done the same
 since the late 1990s (`SQLITE_BUSY`).
 
-## What about Cortex?
+## What about Cor?
 
-Brainy + Cortex compose cleanly under this model:
+Brainy + Cor compose cleanly under this model:
 
-- Cortex stores its column-index segments inside the same `rootDir` (under
+- Cor stores its column-index segments inside the same `rootDir` (under
   `indexes/_column_index/{field}/`).
-- Segments (`*.cidx` files) are **immutable** once written. Cortex mmaps them
+- Segments (`*.cidx` files) are **immutable** once written. Cor mmaps them
   read-only.
 - The `MANIFEST.json` per field is updated via atomic rename — readers see
   either the old or new manifest, never a torn file.
 
-A reader process can safely mmap Cortex segments alongside a live writer
+A reader process can safely mmap Cor segments alongside a live writer
 without coordination. The single Brainy writer lock at
-`<rootDir>/locks/_writer.lock` covers Cortex too, because Cortex segment
+`<rootDir>/locks/_writer.lock` covers Cor too, because Cor segment
 writes happen on the writer's side.
 
 ## Stale-lock detection
@@ -141,7 +141,7 @@ The CLI `brainy inspect` subcommands all do this for you by default
   processes can both succeed at `init()` in writer mode and clobber each
   other's writes. A best-effort warning is logged in writer mode against a
   non-filesystem backend.
-- **Long-running readers** do not automatically pick up new Cortex segments
+- **Long-running readers** do not automatically pick up new Cor segments
   the writer publishes. One-shot inspector calls re-open the store and see
   fresh segments; a reader that stays open for hours sees its column store
   as-of the time it opened.
@@ -150,4 +150,4 @@ The CLI `brainy inspect` subcommands all do this for you by default
 
 - `Brainy.openReadOnly()` — [API reference](../api/brainy.md)
 - `brainy inspect` — [inspection guide](../guides/inspection.md)
-- Cortex columnar storage — see `node_modules/@soulcraft/cortex/README.md`
+- Cor columnar storage — see `node_modules/@soulcraft/cor/README.md`

docs/concepts/storage-adapters.md

@@ -33,7 +33,7 @@ BaseStorage                (type-statistics, lifecycle helpers, generation
 FileSystemStorage          (real filesystem I/O, writer-lock implementation,
                             flush-request watcher, atomic writes)
         ↑
-<your plugin's storage>    (Cortex's MmapFileSystemStorage, etc.)
+<your plugin's storage>    (Cor's MmapFileSystemStorage, etc.)
 ```
 
 When you `extend FileSystemStorage`, your adapter inherits every method on