test_consolidate binds to the developer's real store: suite hangs at 58%, and can mutate production data

[cdeust]

Symptom

tests_py/handlers/test_consolidate.py::TestConsolidateHandler::test_empty_store_runs_clean
hangs indefinitely on any developer machine that has a populated PostgreSQL
store configured. The full suite stops at ~58% and never completes; nothing
times out, because pytest-timeout is not installed (pyproject.toml
configures timeout/timeout_method, and pytest reports both as
PytestConfigWarning: Unknown config option).

Reproduction

CORTEX_RERANKER_OFFLINE=1 python3 -m pytest \
  "tests_py/handlers/test_consolidate.py::TestConsolidateHandler::test_empty_store_runs_clean" -q
# never returns

Measured 2026-07-27. Reproduces identically on main (a2f5053) and on an
unrelated feature branch, so it is not caused by any in-flight change.

Root cause — the test has no store isolation

async def test_empty_store_runs_clean(self):
    from mcp_server.handlers.consolidate import handler
    result = await handler()
    assert result["decay"]["total_memories"] == 0

No fixture, no monkeypatch, no temp database. handler() resolves its
store through get_shared_store(settings.DB_PATH, ...), so it binds to
whatever backend the developer's environment points at — in practice the
real PostgreSQL corpus. The test then runs a full consolidation cycle (decay,
compression, CLS, causal discovery) across every production memory.

The assertion total_memories == 0 shows the intent: it was written against
an empty store. It only passes in CI because CI has no populated database.
That is coverage by accident of environment, not by construction (§13.1 G3:
tests must be deterministic and isolated).

The sibling tests in the same class (test_decay_only, test_compress_only)
share the defect.

Why it matters beyond the hang

A test that silently binds to the developer's production store can also
mutate it — consolidate decays heat, compresses memories to gist/tag,
and advances consolidation stages. Running the suite locally is currently a
write against real data.

Acceptance criteria

1. TestConsolidateHandler binds to an isolated temp store (fixture setting
   CORTEX_MEMORY_STORE_BACKEND=sqlite + a tmp_path DB, clearing
   get_memory_settings cache and reset_shared_store()), so the assertions
   are true by construction rather than by environment.
2. The whole class passes with a populated PostgreSQL database configured in
   the environment.
3. pytest-timeout is installed (or the unknown timeout config keys are
   removed), so a hang fails loudly instead of stalling the suite — the two
   PytestConfigWarnings are themselves a seen defect.
4. A test asserting that running the suite does not write to a store the test
   did not create.

[cdeust]

The same defect exists on the SQLite side, and it is much wider than test_consolidate

While establishing provenance for a suspected regression in #206, I ran the
full suite on the SQLite backend and got 166 failures. Paired control
(same command, git stash push -- mcp_server/, rerun, git stash pop)
showed 165 of them failing identically without the change — so they are not a
regression. They are this issue.

Root cause

tests_py/infrastructure/test_memory_store.py (and ~20 other modules)
construct MemoryStore() / get_shared_store(s.DB_PATH, ...) with no
isolation, so on the SQLite backend they bind to the developer's real
~/.claude/methodology/memory.db.

That database carries an older schema than sqlite_schema.py emits:

heat_base      REAL GENERATED ALWAYS AS (heat)          VIRTUAL,
heat_base_set_at TEXT GENERATED ALWAYS AS (last_accessed) VIRTUAL,
no_decay       INTEGER GENERATED ALWAYS AS (0)          VIRTUAL

whereas sqlite_schema.py:27 declares heat_base_set_at TEXT NOT NULL DEFAULT (datetime('now')). Every insert therefore dies with:

sqlite3.OperationalError: cannot INSERT into generated column "heat_base_set_at"

CREATE TABLE IF NOT EXISTS never reconciles an existing table, so the stale
real DB silently wins over the shipped schema.

It also destroys data, exactly as this issue warns

The store fixture's teardown runs DELETE FROM against
memories, entities, relationships, checkpoints, engram_slots,
memory_archives, schemas, … on whatever store it bound to. On my machine
that was the real ~/.claude/methodology/memory.db. It now reports
select count(*) from memories → 0.

Measured impact

Failures	Cause
131	this issue (fixtures bind to the real, stale memory.db)
35	genuine SQLite parity gap — filed separately as #220
1	the #206 change itself (an allow-list line-number drift; fixed there)

Isolating both CORTEX_MEMORY_DB_PATH and
CORTEX_MEMORY_SQLITE_FALLBACK_PATH to a scratch file drops 166 → 35.
Note that isolating only SQLITE_FALLBACK_PATH is not enough — the handler
tests read the deprecated DB_PATH setting
(memory_config.py:48), so both must be overridden. That split is itself
part of the bug.

Suggested acceptance criteria (in addition to the existing ones)

• A session-scoped fixture points every store construction at a
  per-run temp path; binding to ~/.claude/methodology/ from a test is
  impossible, not merely discouraged.
• A guard test fails if any store under test resolves to a path inside
  the user's real methodology directory.
• DB_PATH and SQLITE_FALLBACK_PATH collapse to one resolved path, so
  isolating the store cannot be done half-way.
• The teardown DELETE FROM loop is replaced by discarding the temp DB.

Measured 2026-07-27 on commit a2f5053.