feat(8.0): API simplification — remove neural()/Db.search, one storage path key, integration→0

8.0 RC cleanup toward "one place per thing, zero-config, no deprecation":

- Remove the `brain.neural()` clustering namespace (ImprovedNeuralAPI + the dead
  legacy NeuralAPI + the neural CLI + neural-only types). Similarity is `find({vector})`
  / `similar({to})`; attribute grouping is the aggregation `GROUP BY` engine. The separate
  entity-extraction / smart-import feature (NeuralImport, NeuralEntityExtractor, SmartExtractor,
  NaturalLanguageProcessor, `brain.extract()`/`brain.nlp()`) is kept.
- Remove `Db.search()`; `find()` is the one query verb (accepts a bare string or FindParams).
  Fix the bundled MCP client, which called a non-existent `brain.search(query, limit)` →
  now `find({ query, limit })`.
- Storage config: collapse to one canonical top-level `path` key. The pre-8.0 aliases
  (`rootDirectory`, `options.*`, `fileSystemStorage.*`) are removed and now THROW with the
  exact rename instead of silently defaulting to `./brainy-data` on upgrade. A single resolver
  feeds createStorage, the 7.x→8.0 migration probe, and the plugin-factory handoff, so a native
  storage provider resolves the identical root (no split-brain).
- Fix `similar({ threshold })`: the min-similarity filter was silently dropped; it is now
  applied as a post-filter on `result.score` (the documented way to bound semantic results).
- Fix `vfs.rename()` on a directory: child path updates spread the entity vector into `update()`
  and failed dimension validation; they are metadata-only updates now.
- Fix `vfs.move()`: copy+delete orphaned the content-addressed content blob (the destination
  shared the source hash, then unlink removed it). `move()` now delegates to `rename()` — an
  in-place path change that preserves the blob and the entity id, for files and directories.
- Fix streaming import: the bulk fast path never flushed mid-import nor signalled queryability.
  Entity writes are now chunked by a progressive flush interval (100 → 1000 → 5000); each chunk
  flushes and emits `progress.queryable`, so imported data is queryable during the import.
- Sweep all docs, comments, and JSDoc for the removed/changed APIs.

Integration suite: 49 files / 588 passed / 0 failed. Unit: 80 files / 1456 passed, no type errors.

docs/architecture/storage-architecture.md

@@ -71,7 +71,7 @@ Brainy 8.0 ships two adapters, both implementing the same `StorageAdapter` inter
 const brain = new Brainy({
   storage: {
     type: 'filesystem',
-    rootDirectory: './data'
+    path: './data'
   }
 })
 ```
@@ -99,15 +99,15 @@ const brain = new Brainy({
 const brain = new Brainy({
   storage: {
     type: 'auto',
-    rootDirectory: './data'
+    path: './data'
   }
 })
 ```
-`'auto'` picks `'filesystem'` when running on Node.js with a writable `rootDirectory`, and falls back to `'memory'` otherwise.
+`'auto'` picks `'filesystem'` when running on Node.js with a writable `path`, and falls back to `'memory'` otherwise.
 
 ## Backup and Off-Site Replication
 
-Brainy 8.0 does not embed cloud SDKs. The on-disk artifact at `rootDirectory` is a plain directory tree of JSON files, so backup is an operator-layer concern. Typical patterns:
+Brainy 8.0 does not embed cloud SDKs. The on-disk artifact at `path` is a plain directory tree of JSON files, so backup is an operator-layer concern. Typical patterns:
 
 - `gsutil rsync -r ./data gs://my-bucket/brainy-data`
 - `aws s3 sync ./data s3://my-bucket/brainy-data`
@@ -180,7 +180,7 @@ High-performance deduplication system for streaming data:
 
 ## Durability
 
-Brainy persists writes to disk through the filesystem adapter. Each save is a rename-based atomic write of a JSON file under the appropriate shard. Operators that need point-in-time recovery should snapshot `rootDirectory` (see [Backup and Off-Site Replication](#backup-and-off-site-replication)).
+Brainy persists writes to disk through the filesystem adapter. Each save is a rename-based atomic write of a JSON file under the appropriate shard. Operators that need point-in-time recovery should snapshot `path` (see [Backup and Off-Site Replication](#backup-and-off-site-replication)).
 
 ## Storage Optimization
 
@@ -210,7 +210,7 @@ await brain.addBatch([
 const brain = new Brainy({
   storage: {
     type: 'filesystem',
-    rootDirectory: './data',
+    path: './data',
     cache: {
       enabled: true,
       maxSize: 1000,   // Maximum cached items
@@ -260,7 +260,7 @@ await brain.restore('/backups/2026-06-11', { confirm: true })
 ### Move to a new directory
 ```typescript
 // A snapshot directory is a complete store: restore it into a fresh brain
-const brain = new Brainy({ storage: { type: 'filesystem', rootDirectory: './new' } })
+const brain = new Brainy({ storage: { type: 'filesystem', path: './new' } })
 await brain.init()
 await brain.restore('/backups/2026-06-11', { confirm: true })
 ```
@@ -298,7 +298,7 @@ console.log(stats)
 1. **Read-heavy**: Enable caching and let the OS page cache do its job
 2. **Write-heavy**: Batch operations and tune the cache `maxSize`
 3. **Real-time**: FileSystem with periodic snapshots
-4. **Archival**: Snapshot `rootDirectory` to cold object storage on a schedule
+4. **Archival**: Snapshot `path` to cold object storage on a schedule
 5. **Large-scale**: Rely on metadata/vector separation + UUID sharding
 
 ### Monitor and Maintain