docs: sync clice

en/clice/design/incremental-parse.md

@@ -86,7 +86,7 @@ The benefit of this model is avoiding wasteful compilations during rapid success
 PCH files on disk are named by a hash of the preamble content together with the frontend-relevant compile flags, directories, and clang version (e.g., `a3f7e8c1d2b4f6e9.pch`), implementing content-addressed storage. This provides two benefits:
 
 - **Disk sharing**: Different files whose preamble content and compile configuration agree naturally share the same PCH file on disk, with no additional deduplication logic needed.
-- **Cross-session persistence**: PCH cache metadata (path, hash, boundary, dependency snapshot) is serialized to a `cache.json` file on disk. On server restart, this metadata is loaded and each PCH's validity is verified through two-layer invalidation detection, avoiding the need to rebuild all PCHs on a cold start.
+- **Cross-session persistence**: PCH cache metadata (path, hash, boundary, dependency snapshot) is persisted into the index database alongside the symbol index. On server restart, this metadata is loaded and each PCH's validity is verified through two-layer invalidation detection, avoiding the need to rebuild all PCHs on a cold start.
 
 When preamble content changes, the new PCH uses a different hash for its filename and the old file becomes orphaned. A cleanup mechanism periodically reclaims orphaned PCH files that have not been used beyond a certain age.
 
@@ -172,7 +172,7 @@ For non-self-contained headers, the compilation context system synthesizes a pre
 
 ### Cache Persistence
 
-PCH and PCM cache metadata are persisted to disk via a `cache.json` file. This file is updated after each successful build and loaded on server startup. Writes use a write-to-temp-then-atomic-rename pattern to prevent file corruption from mid-write crashes.
+PCH and PCM cache metadata are persisted as a metadata blob in the index database. The blob is flushed shortly after each successful build and loaded on server startup; blob writes are atomic, and each record additionally pins the exact artifact file it describes (size, mtime, filesystem identity, content hash), so a crash between publishing an artifact and flushing its metadata is detected and the artifact re-verified instead of trusted.
 
 After loading the cache on startup, all PCH entries are validated through two-layer invalidation detection. Stale entries are automatically rebuilt on the next compilation, requiring no special cache consistency recovery logic.
 

en/clice/design/module-graph.md

@@ -139,7 +139,7 @@ All compilation tasks are managed through kota::task_group, providing structured
 
 PCM files use content-addressed path naming — the filename is determined by the module name and a hash of the compilation arguments, stored in a dedicated cache directory. This is fully isolated from build system artifacts, avoiding file-locking conflicts.
 
-PCM cache uses two-layer staleness detection: first comparing dependency files' modification times (mtime), then re-hashing content when times have changed. Recompilation only occurs when dependency content has actually changed, avoiding unnecessary rebuilds caused by "touch without modification." Cache metadata is persisted to `cache.json` on disk and can be restored on server restart.
+PCM cache uses two-layer staleness detection: first comparing dependency files' modification times (mtime), then re-hashing content when times have changed. Recompilation only occurs when dependency content has actually changed, avoiding unnecessary rebuilds caused by "touch without modification." Cache metadata is persisted into the index database and restored on server restart.
 
 ### Integration with the Compilation Pipeline
 

en/clice/design/overview.md

@@ -20,7 +20,7 @@ clice is a brand-new C++ language server, redesigned from the architecture level
 
 General-purpose utilities and infrastructure shared by all other modules.
 
-- `PathPool`: Internalizes file paths as `uint32_t` identifiers, used as stable file identifiers throughout the system
+- `FileTable` (in `src/vfs/`): Internalizes file paths as `uint32_t` identifiers used as stable file identifiers throughout the system, and holds the shared per-file facts derived from them — disk state, content versions, scan results, directory listings
 - `FuzzyMatcher`: Token-aware fuzzy matching for code completion and symbol search
 - Markup / Doxygen: Parsing and formatting of documentation comments
 - Logging, filesystem abstractions, string utilities, etc.
@@ -87,7 +87,7 @@ The language server's core runtime, responsible for assembling all the layers ab
 
 **`state/`** — Project and document state, plus the invalidation machinery.
 
-- `Workspace`: Project-level global state — the compilation database, toolchain, path pool, dependency graph, cache store, and project index. Core invariant: unsaved buffer contents of open files never modify the `Workspace` -- it only reflects the state on disk
+- `Workspace`: Project-level global state — the compilation database, toolchain, file table, dependency graph, cache store, and project index. Core invariant: unsaved buffer contents of open files never modify the `Workspace` -- it only reflects the state on disk
 - `Session` / `SessionStore`: The editing state for each open file (buffer contents, document version, in-memory index, PCH reference, etc.), created on didOpen and destroyed on didClose; `SessionStore` owns the table of open sessions and the buffer-synchronization logic
 - `Invalidator`: The invalidation engine — folds file events (buffer opens/saves, on-disk changes, compilation-database reloads, worker crashes) into a deduplicated set of invalidation effects
 - `FileTracker`: Stat-polling discovery of changes that happen outside the editor (a regenerated `compile_commands.json`, `git checkout`), feeding events to the `Invalidator`

en/clice/guide/configuration.md

@@ -50,14 +50,6 @@ Paths searched for compile_commands.json — file paths, or directories to look
 
 Build the background index that serves cross-TU features (find references, workspace symbols, ...).
 
-### `project.index_db`
-
-| Type     | Default  |
-| -------- | -------- |
-| `string` | `"lmdb"` |
-
-Index persistence backend: "lmdb" (single database file) or "files" (one file per blob).
-
 ### `project.readonly`
 
 | Type     | Default |