fix(core): remove runtime ALTER TABLE from vector init

[phernandez]

Summary

• remove inline ALTER TABLE search_vector_chunks migration logic from Postgres vector table initialization
• keep runtime bootstrap limited to CREATE TABLE IF NOT EXISTS for fresh installs
• add a unit regression test that asserts _ensure_vector_tables() never alters the chunk table schema at runtime

Testing

• uv run pytest tests/repository/test_postgres_search_repository_unit.py
• uv run ruff check src/basic_memory/repository/postgres_search_repository.py tests/repository/test_postgres_search_repository_unit.py
• uv run pytest tests/repository/test_postgres_search_repository.py::test_postgres_dimension_mismatch_triggers_table_recreation (skipped in this environment)

Closes #727

[github-actions]

Claude finished @phernandez's task in 1m 29s —— View job

---

Code Review: fix(core): remove runtime ALTER TABLE from vector init

• Gather context and read changed files
• Review code quality and standards
• Check testing and documentation
• Verify architecture compliance
• Post final review

---

Summary: This PR correctly moves schema evolution for search_vector_chunks (entity_fingerprint, embedding_model columns) out of the runtime bootstrap and into a proper Alembic migration (m6h7i8j9k0l1). The fix is clean, well-motivated, and adds a useful regression test.

---

Checklist Results

Code Quality & Standards

• Follows Basic Memory's coding conventions — new decision-point comments on lines 294–298 follow the literate programming style exactly
• Python 3.12+ type annotations and async patterns — correct throughout
• SQLAlchemy 2.0 best practices — uses text() with parameterized queries
• 100-character line length maintained
• No commented-out code blocks

Testing & Documentation

• Regression test added (TestEnsureVectorTablesSchemaBootstrapping) — well-designed, mocks the session and asserts on SQL text
• Test covers the specific failure mode: assert not any("ALTER TABLE search_vector_chunks" in sql ...)
• Confirms correct positive behavior: CREATE TABLE for chunks and embeddings both fire
• Confirms _vector_tables_initialized is set and commit is called exactly once
• 100% coverage maintained — removed code has no remaining branches

Basic Memory Architecture

• Schema change is in Alembic migration m6h7i8j9k0l1_add_vector_sync_fingerprints.py — proper home for schema evolution
• Runtime bootstrap (_ensure_vector_tables) is now correctly limited to CREATE TABLE IF NOT EXISTS for fresh installs only
• The CREATE TABLE IF NOT EXISTS search_vector_chunks in the bootstrap already includes entity_fingerprint and embedding_model columns — fresh installs get the full schema without needing the migration path, which is correct

Security & Performance

• Removes a real concurrency hazard — ALTER TABLE at runtime during indexing can deadlock; eliminating it is a correctness fix, not just style
• No credentials, hardcoded secrets, or Unicode in log output

Compatibility

• No Windows path issues; no emoji/Unicode in output

---

Notes

Migration + runtime bootstrap alignment is correct. The existing migration h1b2c3d4e5f6 creates the chunks table without the new columns; m6h7i8j9k0l1 adds them for existing installs. The runtime CREATE TABLE IF NOT EXISTS in _ensure_vector_tables already has all columns in the DDL, so fresh installs bypass both migrations for this table and get the right schema immediately. No gap.

Minor observation (non-blocking): test_initialization_never_alters_chunk_table_schema does not assert that CREATE EXTENSION IF NOT EXISTS vector was executed. If desired, a assert any("CREATE EXTENSION IF NOT EXISTS vector" in sql ...) could be added for completeness, but the current coverage of the actual regression is sufficient.

Overall: Clean, correct removal. The approach is consistent with the codebase's principle of "schema evolution in Alembic, runtime bootstrap for fresh installs only." The regression test is a good long-term guard against this pattern creeping back in. Approved.