[mikemikimike]

Fixes #1333

Summary

The CLI analytics helper starts a background request thread for the cloud promo path. Because the thread was non-daemon, one-shot commands such as bm schema validate could finish their work and output while Python interpreter shutdown waited indefinitely for the analytics request.

This change makes the best-effort analytics thread daemonized, so analytics cannot keep the CLI process alive. The existing request timeout and silent failure behavior are unchanged. A regression assertion verifies the thread is created as a daemon.

Tests

• uv run --frozen pytest tests/cli/test_analytics.py tests/cli/test_cli_schema.py -q --no-cov (28 passed)
• uv run --frozen ruff check src/basic_memory/cli/analytics.py tests/cli/test_analytics.py
• uv run --frozen ruff format --check src/basic_memory/cli/analytics.py tests/cli/test_analytics.py
• git diff --check

[phernandez]

Thanks for looking at #1333. I dug into it with a clean-env repro on 3.13, and the analytics thread turns out not to be the cause: the hang reproduces non-interactively, where the promo (and therefore track()) never runs, and the surviving thread in both my dump and the reporter's sample is an AnyIO worker thread parked in queue.get, not a socket wait. bm tool schema-validate also runs the same promo callback and exits fine.

The actual cause is nest_asyncio (applied in alembic/env.py on Python < 3.14) swallowing the done-callback anyio uses to stop its worker, plus a sync FastAPI dependency that dispatched one — fixed in #1349. The analytics thread being non-daemon is deliberate (the 3s request timeout bounds it), so I'd rather not flip it as part of this bug. Closing in favour of #1349; appreciate the PR.