Contain the engine behind one module

Issue #18 §C1. Eighty-three files named the `tinycortex` crate, in two hundred
and ninety-six places. That made the engine's shape an ambient fact of the whole
crate rather than a dependency anyone had chosen, and made "what would a second
engine have to provide?" a question nobody could answer without reading all of
them.

Every one now goes through `core/src/engine/backend.rs`, which re-exports the
engine's memory surface and is the only file outside the seam that names it.
Outside `core/src/engine/`, references to the crate are zero.

Re-exporting rather than wrapping is deliberate. A wrapper over three hundred
call sites would be a second surface to keep in step with the first, which is
the failure §A1 had just finished deleting. What this buys is not insulation —
the call sites use the engine's API verbatim — but a single enumerable place
that names it.

The seam is `engine`, not `tinycortex`. §C1's text says `core/src/tinycortex/`,
but its own acceptance criterion asks that `grep -rl tinycortex core/src` match
only files under that module, and those two cannot both hold: with the module
named after the engine, every call site reads `crate::tinycortex::…` and matches.
Naming the seam for its role rather than for one engine satisfies the criterion
and is the better name regardless — a seam named after the thing it is meant to
make replaceable is the coupling this section removes. The module was `pub` but
had no consumer outside this crate, so the rename breaks nothing.

The workspace root and the module crate each gain a `[patch]` for the contract's
git dependency. Patch tables apply only from the root being built, and the
module crate is its own root; without its own entry cargo resolves the git copy
alongside the path copy and `MemoryTaint` from one is not the same type as from
the other. Found by the compiler, not predicted.

What is left matching `tinycortex` outside the seam is 82 log-message strings
and a `tinycortex_kv` accessor name. Neither is a crate reference, and renaming
the accessor is cosmetic churn §C1 does not ask for. Two stale doc comments
describing a "thirteen-family `tinycortex_api` contract" are corrected — since
§A1 the contract is `tinymemory-api`, and it has eighteen families.

Acceptance, measured: 83 files naming the engine crate outside the seam, now 0.

Refs #18 (§C1)

Author: YellowSnnowmann

core/src/conversations/blocking.rs

@@ -1,7 +1,7 @@
 //! Async wrappers that run the conversation store's **blocking** operations on
 //! tokio's blocking pool (#5156).
 //!
-//! Every `tinycortex::memory::conversations` entry point is synchronous, and
+//! Every `crate::engine::backend::conversations` entry point is synchronous, and
 //! each one takes the process-global `CONVERSATION_STORE_LOCK` — a
 //! `parking_lot::Mutex` — and then does fsync'd JSONL file IO while holding it.
 //! Calling one directly from an `async fn` therefore parks a tokio **worker**
@@ -35,9 +35,9 @@
 
 use std::path::PathBuf;
 
-use tinycortex::memory::conversations as store;
+use crate::engine::backend::conversations as store;
 
-use tinycortex::memory::conversations::{
+use crate::engine::backend::conversations::{
     ConversationMessage, ConversationMessagePatch, ConversationPurgeStats, ConversationStore,
     ConversationThread, CreateConversationThread, CrossThreadHit,
 };

core/src/conversations/mod.rs

@@ -4,7 +4,7 @@
 //! append-only in `threads.jsonl`; each thread's messages in a dedicated JSONL
 //! file). The store / inverted-index / tokenizer / types engine is the crate's
 //! (a byte-identical port, incl. the D1 rank-before-materialize fix), and
-//! consumers name `tinycortex::memory::conversations` directly — this module no
+//! consumers name `crate::engine::backend::conversations` directly — this module no
 //! longer re-exports that surface under a second path.
 //!
 //! Host-retained:

core/src/diff/mod.rs

@@ -14,12 +14,12 @@
 //! the ledger is a derived view used purely for change tracking.
 //!
 //! W7: the snapshot/diff/checkpoint/ledger engine is now
-//! `tinycortex::memory::diff::DiffEngine` (a byte-identical port over the same
+//! `crate::engine::backend::diff::DiffEngine` (a byte-identical port over the same
 //! `<workspace>/memory_diff/repo` git layout). This module is a thin host shim:
 //! [`ops`] async-wraps the engine, [`source`] supplies the chunk-store item
 //! seam (`DiffEngine`'s `SnapshotItemSource`), and `rpc`/`schemas`/`tools`
 //! keep the RPC + agent surface. The wire types are the crate's, named directly
-//! (`tinycortex::memory::diff::types`) rather than through a host re-export
+//! (`crate::engine::backend::diff::types`) rather than through a host re-export
 //! module.
 //!
 //! Features:
@@ -65,7 +65,7 @@ pub mod source;
 // `memory::diff::{types, source}` are serde-only wire types and stay compiled;
 // only the git-touching `ledger`/`DiffEngine` half sits behind `git-diff`. A
 // stub copy would be a second definition of one serde shape, free to drift.
-pub use tinycortex::memory::diff::types::{
+pub use crate::engine::backend::diff::types::{
     ChangeKind, Checkpoint, CrossSourceDiff, DiffResult, DiffSummary, ItemChange, Snapshot,
     SnapshotTrigger,
 };

core/src/diff/ops.rs

@@ -1,5 +1,5 @@
 //! Business logic for memory diff — thin host async wrappers over
-//! `tinycortex::memory::diff::DiffEngine` (W7).
+//! `crate::engine::backend::diff::DiffEngine` (W7).
 //!
 //! The snapshot/diff/checkpoint/ledger engine is the crate's; the git ledger it
 //! writes lives at the same `<workspace>/memory_diff/repo` path with the same
@@ -16,10 +16,10 @@ use tinymemory_api::host::test_support::TestHostConfig;
 use crate::sources::types::MemorySourceEntry;
 use crate::Config;
 
-use tinycortex::memory::diff::{DiffEngine, SourceDescriptor};
+use crate::engine::backend::diff::{DiffEngine, SourceDescriptor};
 
 use super::source::ChunkStoreItemSource;
-use tinycortex::memory::diff::types::*;
+use crate::engine::backend::diff::types::*;
 
 /// A crate [`SourceDescriptor`] from a host source entry.
 fn descriptor(source: &MemorySourceEntry) -> SourceDescriptor {
@@ -101,7 +101,7 @@ pub async fn list_snapshots(
     let source_id = source_id.map(str::to_string);
 
     tokio::task::spawn_blocking(move || -> anyhow::Result<Vec<Snapshot>> {
-        let ledger = tinycortex::memory::diff::Ledger::open(&workspace_dir)?;
+        let ledger = crate::engine::backend::diff::Ledger::open(&workspace_dir)?;
         ledger.list_snapshots(source_id.as_deref(), limit)
     })
     .await
@@ -310,7 +310,7 @@ pub async fn cleanup(config: &Config, older_than_days: u32) -> Result<u64, Strin
 #[cfg(test)]
 mod tests {
     use super::*;
-    use tinycortex::memory::diff::{Ledger, SnapshotMeta};
+    use crate::engine::backend::diff::{Ledger, SnapshotMeta};
 
     fn test_config() -> TestHostConfig {
         crate::test_seams::init();

core/src/diff/source.rs

@@ -1,6 +1,6 @@
 //! The host implementation of the crate diff engine's chunk-source seam.
 //!
-//! `tinycortex::memory::diff::DiffEngine` is generic over a
+//! `crate::engine::backend::diff::DiffEngine` is generic over a
 //! [`SnapshotItemSource`]: during
 //! `take_snapshot` (directly, and transitively from `create_checkpoint` for any
 //! source lacking a baseline) it asks the source for a source's already-ingested
@@ -22,7 +22,7 @@
 use std::collections::HashMap;
 use std::sync::Arc;
 
-use tinycortex::memory::diff::{extract_item_id, SnapshotItem, SnapshotItemSource};
+use crate::engine::backend::diff::{extract_item_id, SnapshotItem, SnapshotItemSource};
 
 #[cfg(test)]
 use tinymemory_api::host::test_support::TestHostConfig;

core/src/diff/stub.rs

@@ -26,7 +26,7 @@
 use crate::sources::types::MemorySourceEntry;
 use crate::Config;
 
-use tinycortex::memory::diff::types::{Checkpoint, CrossSourceDiff, Snapshot};
+use crate::engine::backend::diff::types::{Checkpoint, CrossSourceDiff, Snapshot};
 
 /// The message every disabled entry point returns.
 ///

core/src/engine/backend.rs

@@ -0,0 +1,59 @@
+//! The engine's own memory surface, reached through one door.
+//!
+//! Issue #18 §C1 asks that nothing outside this module name the `tinycortex`
+//! crate. Eighty-three files did, in two hundred and ninety-six places, which
+//! made the engine's shape an ambient fact of the whole crate rather than a
+//! dependency anyone had chosen — and made "what would a second engine have to
+//! provide?" a question no one could answer without reading all of them.
+//!
+//! Re-exporting rather than wrapping is deliberate. A wrapper layer over three
+//! hundred call sites would be a second surface to keep in step with the first,
+//! which is the failure §A1 had just finished deleting. What this buys is not
+//! insulation from the engine's API — the call sites still use it verbatim —
+//! but a single place that *names* it, so the coupling is enumerable: this file
+//! is the list of everything `tinymemory-core` needs an engine to provide.
+//!
+//! # Why this is not `MemoryProvider`
+//!
+//! §A3 proposes routing these call sites through `&dyn MemoryProvider` instead.
+//! That is not possible, and the reason is worth recording where the next
+//! reader will find it. Core does not *consume* the engine's memory API; it
+//! shares the engine's SQLite database. Thirty-four files here hold a
+//! `rusqlite::Transaction` or a `Connection`, and the entry points they call
+//! take them:
+//!
+//! ```text
+//! upsert_buffer_tx(tx: &Transaction<'_>, buf: &Buffer) -> Result<()>
+//! shared_connection(config: &MemoryConfig) -> Result<Arc<PMutex<Connection>>>
+//! ```
+//!
+//! Serving those through the contract would put `rusqlite` in
+//! `tinymemory-api`, which its own manifest forbids and CI now enforces. The
+//! honest description is that core and the engine co-implement one store, and
+//! separating them is a decomposition rather than a routing change.
+//!
+//! Nested under a module rather than re-exported flat because the seam already
+//! has its own `ingest` and `sync` modules, which are host-side pieces and
+//! not the engine's.
+
+// The engine's submodules.
+pub use tinycortex::memory::{
+    archivist, chunks, conversations, diff, graph, health, ingest, people, queue, retrieval, score,
+    sources, store, sync, tool_memory, tree, types,
+};
+
+// …and the items it re-exports at its own top level, which call sites reach for
+// by the same short paths. Listed rather than globbed so this file stays the
+// enumerable answer to "what does core need an engine to provide".
+pub use tinycortex::memory::{
+    GraphRelationRecord, InMemoryMemoryStore, MemoryCategory, MemoryConfig, MemoryEngineError,
+    MemoryEngineResult, MemoryEntry, MemoryId, MemoryInput, MemoryItemKind, MemoryKvRecord,
+    MemoryQuery, MemoryRecord, MemoryResult, MemoryStore, MemoryTaint, NamespaceDocumentInput,
+    NamespaceMemoryHit, NamespaceQueryResult, NamespaceRetrievalContext, NamespaceSummary,
+    RecallOpts, RetrievalScoreBreakdown, SearchHit, StoreError, StoredMemoryDocument,
+    WeightProfile, GLOBAL_NAMESPACE,
+};
+
+// The storage trait itself. Since §A2 this is the contract's trait, not the
+// engine's — the engine re-exports the same one.
+pub use tinycortex::memory::Memory;