#3364: refactor(memory): extract vector management to dedicated module

- Extract sqlite-vec loading and vector table lifecycle to VectorManager class - Move ~70 lines of vector logic from manager.ts to vector/vector-manager.ts - manager.ts delegates vector operations to VectorManager instance - Zero breaking changes to public API - All existing tests should pass Part of memory modularization effort to reduce manager.ts complexity (2179 → 2107 lines) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR refactors memory vector support by extracting sqlite-vec extension loading and vector table lifecycle into a new `VectorManager` (`src/memory/vector/vector-manager.ts`). `MemoryIndexManager` (`src/memory/manager.ts`) now delegates vector readiness/state and table resets to this module, reducing `manager.ts` complexity without changing the public API. Main integration points are `ensureVectorReady()`/`probeVectorAvailability()` and reindex/compaction paths where the DB handle is swapped and vector state is reinitialized. <h3>Confidence Score: 3/5</h3> - This PR is likely safe to merge after fixing one error-path state restoration issue. - The refactor is largely a mechanical extraction into `VectorManager`, and most call sites delegate cleanly. However, in the reindex/compaction error path the `VectorManager` is not recreated when restoring the original DB, which can leave the instance bound to a closed temp database and break subsequent vector operations. Addressing that should bring this back to low risk. - src/memory/manager.ts (runSafeReindex restore path) <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->