feat(fts): split compaction into dedicated module and add crash-safe LSM merge

The monolithic compact.rs handler and inverted.rs grew beyond the 500-line
limit and mixed unrelated concerns. Both are replaced with proper directory
modules:

- handlers/compact/ — budget tracking, FTS merge logic, maintenance
  orchestration, segment-level helpers, stats, and runner are now separate
  files. The module covers vector, CSR, and FTS compaction in a single
  coordinated handler so the maintenance cycle has one entry point.

- engine/sparse/inverted/ — InvertedIndex is split into core, indexing,
  search, compaction, synonyms, and error sub-modules following the
  one-concern-per-file rule.

Two new operations are added to the redb FTS backend:

- compact_commit: writes the merged segment and removes all source segments
  inside a single redb write transaction. A crash mid-compaction leaves the
  original segments intact; the maintenance cycle retries on the next pass.
  Double-counted postings from a partial commit are no longer possible.

- list_all_fts_collections: scans the SEGMENTS table to enumerate every
  (tenant, collection) pair that has at least one segment, so maintenance
  can discover compaction candidates without a separate registry.

The remove_segment path propagates the redb error instead of silently
swallowing Ok(None); a corrupt index or aborted transaction now surfaces
at the call site.

Two executor accessors are added so integration tests and bootstrapping
code can prime segments and resolve tenant→database mappings without
going through the normal indexing path:

- CoreLoop::fts_write_segment — writes a raw segment blob directly into
  the LSM segment store, bypassing the memtable flush path.
- CoreLoop::fts_list_segments — returns the segment IDs for a collection.
- ExecutorMaintenance::set_tenant_database — primes the tenant→database
  map so the maintenance budget tracker can resolve per-database CPU caps
  for tenants that have not yet been seen in a request.

The new fts_compaction_budget integration test verifies that the
per-database maintenance CPU budget gates FTS LSM compaction: a database
under its cap has segments merged, while a database with its budget
pre-exhausted defers compaction without touching its segments.

Author: farhan-syah

nodedb/src/data/executor/core_loop/accessors.rs

@@ -163,4 +163,40 @@ impl CoreLoop {
             })
             .unwrap_or(0)
     }
+
+    /// Write a raw segment blob directly into the FTS LSM segment store for
+    /// a given `(tenant, collection)`.
+    ///
+    /// This bypasses the memtable flush path and is intended for maintenance
+    /// tests and bootstrapping code that need to pre-populate a known number
+    /// of L0 segments without indexing documents. In production code,
+    /// segments are written automatically when the FTS memtable crosses its
+    /// flush threshold.
+    pub fn fts_write_segment(
+        &self,
+        tenant: crate::types::TenantId,
+        collection: &str,
+        segment_id: &str,
+        data: &[u8],
+    ) -> crate::Result<()> {
+        use nodedb_fts::backend::FtsBackend;
+        self.inverted
+            .backend()
+            .write_segment(tenant.as_u64(), collection, segment_id, data)
+    }
+
+    /// Return the list of FTS LSM segment IDs for a `(tenant, collection)`.
+    ///
+    /// Used by maintenance tests to verify that compaction reduced the
+    /// segment count at a given level.
+    pub fn fts_list_segments(
+        &self,
+        tenant: crate::types::TenantId,
+        collection: &str,
+    ) -> crate::Result<Vec<String>> {
+        use nodedb_fts::backend::FtsBackend;
+        self.inverted
+            .backend()
+            .list_segments(tenant.as_u64(), collection)
+    }
 }

nodedb/src/data/executor/core_loop/maintenance.rs

@@ -52,6 +52,20 @@ impl CoreLoop {
         self.tenant_database_map.entry(tenant).or_insert(db);
     }
 
+    /// Register a `TenantId → DatabaseId` mapping.
+    ///
+    /// In production the mapping is populated lazily from request headers.
+    /// This method allows tests and bootstrapping code to prime the mapping
+    /// explicitly so the maintenance budget tracker can resolve per-database
+    /// caps for tenants that have not yet processed any requests.
+    pub fn set_tenant_database(
+        &mut self,
+        tenant: crate::types::TenantId,
+        db: nodedb_types::DatabaseId,
+    ) {
+        self.tenant_database_map.insert(tenant, db);
+    }
+
     /// Resolve the `DatabaseId` for a `TenantId`. Falls back to
     /// `DatabaseId::DEFAULT` when the mapping has not been seen yet.
     pub(in crate::data::executor) fn database_for_tenant(