[BUG] .bmignore shields already-synced content from removal (no supported deletion path)

[ryanstraight]

Bug Description

.bmignore is applied to both ends of bm cloud sync and bm cloud bisync, so ignored paths are invisible to the sync engine — it neither uploads nor deletes them. As a result, if content syncs to a cloud tenant and is later added to .bmignore (the natural remediation when you discover sensitive files leaked), there is no supported command to remove the cloud copy. It persists in the tenant DB, queryable via search_notes and the REST API, indefinitely. The documented way to keep data out of the cloud actively prevents cleaning up data already there.

Steps To Reproduce

1. Install version 0.20.3 (pip install basic-memory) and authenticate a cloud tenant (bm cloud login).
2. Sync a note to a cloud project: bm cloud bisync --name <project>. Confirm it is returned by search_notes.
3. Add that note's path to ~/.basic-memory/.bmignore.
4. Run bm cloud sync --name <project> (documented as "make cloud identical to local").
5. Run search_notes again — the note is still returned, and the entity is still GET-able via GET /v2/projects/<project_id>/knowledge/entities/<entity_id>. No CLI command removes it.

Expected Behavior

bm cloud sync ("make cloud identical to local") should delete cloud content that is now ignored / absent from the filtered local set — or there should be an explicit bm cloud prune / purge-ignored command. Adding a file to .bmignore should not permanently strand its cloud copy.

Actual Behavior

bm cloud sync completes with no deletion; ignored cloud orphans are permanent through all supported tooling. The only removal path we found is the undocumented REST API: DELETE /v2/projects/<project_id>/knowledge/entities/<entity_id> (per-entity) or POST /v2/projects/<project_id>/knowledge/delete-directory (bulk).

Environment

• OS: Windows 11 (10.0.26220)
• Python version: 3.13.2
• Basic Memory version: 0.20.3
• Installation method: pip (--user)
• Claude Desktop version (if applicable): N/A (reproduced via CLI + cloud REST API)

Additional Context

• Impact: a user who correctly adds leaked sensitive files (private personal data they want off a hosted tenant) to .bmignore believes they have remediated, while the data remains on a hosted, non-private-flagged tenant reachable by any connected client.
• Secondary observation: delete_project (MCP) and bm project remove --cloud both returned an empty/opaque error (Error removing project: with no detail) against a large project, so the project-level removal path also could not be exercised to completion.
• Related issues (checked — distinct): [BUG] bmignore weirdness #819 is a different .bmignore bug (patterns not matching hidden dirs on upload); CLI: support cloud → local direction in bm cloud sync #858 adds a cloud→local sync direction. Neither addresses content that already synced and is then ignored.

Possible Solution

Do not let the ignore filter shield existing cloud content from deletion: bm cloud sync should remove cloud entities absent from the filtered local set, or add a dedicated prune/purge command. The apparent cause is that the ignore filter is applied symmetrically when computing the sync plan, so ignored paths are excluded from the "to delete" set as well as the "to upload" set.