Summary

Fixes #1006 (chromadb 1.5.x queue-stall regression) and #487 (chromadb 0.6.x fails on Python 3.13/3.14 due to Pydantic V1 incompatibility) via a single pin change:

```diff

• "chromadb>=0.5.0",

• "chromadb>=1.5.4,<2",
  ```

Plus a regenerated `uv.lock` and two docstring/comment updates in `mempalace/init.py` and `mempalace/migrate.py` that reflect the new behavior (chromadb 1.x auto-migrates 0.4.1+ palaces; posthog telemetry is now a no-op stub).

Provenance

This is a maintainer-sponsored integration of @Legion345's work from #581. The two commits below carry Legion345 as the original git author, preserving their authorship unchanged. I'm landing this on a parallel branch to move the fix through the maintainer path while the #581 thread sits on community re-review after its Apr 17 rebase.

Credits:

• @Legion345 — authored both commits; diagnosed the Pydantic V1 / Python 3.13/3.14 incompatibility and chose 1.5.4 as the correct floor (commits preserved via cherry-pick)
• @web3guru888 — approved in #581 on Apr 11 after substantive review: "The fix is correct for Python 3.13/3.14, and the diagnosis is right — Pydantic V1 is the blocker, and 1.5.4 is where chromadb fully dropped it."
• @jphein — production-validated the 0.6.3 → 1.5.7 auto-migration on a 50K-drawer palace: 648 tests pass, 20% test-suite speedup, zero API breakage

Why this instead of the closed #1008

#1008 took the opposite direction — `chromadb<1.0`. A code review on that PR flagged that the `<1.0` cap reintroduces a documented breaking incompatibility with Python 3.13+ (see #487 for the exact Pydantic V1 `ConfigError`), reversing the intent of #302 which specifically widened chromadb to fix that.

Raising the floor to 1.5.4 is the correct direction: it excludes the broken 1.5.3-and-below versions (covering the known Pydantic V1 cutoff), keeps Python 3.13+ working, and adds a `<2` safety cap to guard future chromadb major breakage per @web3guru888's feedback thread.

Open question on the queue-stall floor

The #1006 reproduction tested chromadb 1.5.6 and 1.5.8 — both stall in the same way (embeddings queued, never materialized; search returns ghosts). I have NOT tested 1.5.4 against that reproduction.

If 1.5.4 is clean on the queue-stall path, this pin is sufficient as-is. If 1.5.4 also stalls, a follow-up tightens the floor (e.g., to the specific patch where the processor was fixed) on top of this PR — strictly narrower than the blanket `<1.0` approach, and no regression for Python 3.13+ users.

Relationship to #581

Happy to close this in favor of #581 if @Legion345 or the maintainers prefer — the diff is Legion345's verbatim. This PR exists as a sponsored merge path, not competing work.

Supersedes / closes

• Closes fix: pin chromadb to <1.0 to avoid 1.5.x queue-stall regression (#1006) #1008 (the `<1.0` approach — already closed)
• Fixes bug: fresh pip install mempalace silently broken on chromadb 1.5.x — writes queued but never flush, search returns ghosts #1006 (queue-stall), chromadb<0.7 pin breaks MCP server on Python 3.14 #487 (Pydantic V1 on Py 3.13/3.14)
• Parallel to fix: upgrade chromadb to >=1.5.4 for python 3.13/3.14 compatibility #581 (same diff, different merge path)

Test plan

• Fresh venv on Python 3.11.x + `pip install -e .` — chromadb resolves within `>=1.5.4,<2`
• Fresh venv on Python 3.13.x + `pip install -e .` — import succeeds (no Pydantic V1 ConfigError per chromadb<0.7 pin breaks MCP server on Python 3.14 #487)
• `mempalace mine --mode convos` — drawers land AND flush (verifies bug: fresh pip install mempalace silently broken on chromadb 1.5.x — writes queued but never flush, search returns ghosts #1006 fix: `embeddings_queue` drains, `col.count()` matches filed count)
• `mempalace status` — shows filed drawers
• `mempalace search "query"` — returns real content with non-None metadata
• Existing palace on chromadb 0.6.x opens cleanly under 1.5.4+ (auto-migration per @jphein's validation)