[BUG] build_context fails to expand cross-project wiki-links even when no project is specified

[chris-hatton]

Bug Description

When calling build_context without specifying a project, wiki-links that reference notes in other projects (e.g. [[org/company-standards]]) are stored as valid cross-project relations but cannot be expanded. The system has the correct entity ID but returns null for the entity name and produces identical broken output regardless of traversal depth.

Steps To Reproduce

1. Install basic-memory (any recent version)
2. Configure two projects in basic-memory (e.g. myproject and org)
3. Create a note in project A containing a wiki-link to a note in project B, e.g. [[org/company-standards]]
4. Index the note (automatic on write)
5. Call build_context on the project A note without specifying a project:
   bm tool build-context "myproject/test-note"
6. Observe the response: to_entity is null and to_entity_id holds a valid ID (e.g. 100)
7. Increase depth from 1 to 2 and observe the output is identical — no expansion occurs

Expected Behavior

build_context with no project specified should be able to expand wiki-links across project boundaries, returning the linked note's content and recursively expanding its relations.

Actual Behavior

• The wiki-link is persisted as a cross-project relation with a valid to_entity_id (e.g. 100)
• The response shows to_entity: null despite a valid entity ID existing
• Both depth=1 and depth=2 produce identical broken output
• Zero related entities are returned; the cross-project relation cannot be expanded through any traversal depth

Environment

• OS: macOS (likely cross-platform)
• Python version: 3.12
• Basic Memory version: current (pip-installed)
• Installation method: uv
• Backend: SQLite

Additional Context

The blocking mechanism is in find_related() (basic_memory/services/context_service.py lines 336-338). The recursive CTE query appends AND e.project_id = :project_id and AND e_from.project_id = :project_id at every depth level. Every traversal step is gated to the primary note's project_id, so cross-project entity IDs are never resolved — even though they are stored correctly.

This makes cross-project wiki-links structurally one-way: writing [[org/X]] succeeds, but no retrieval path can follow it.

Possible Solution

The project filter in find_related() needs to either:

1. Skip the project filter when the target entity is known to exist in a different project (entity ID is already valid — the SQL just won't look there), or
2. Treat cross-project wiki-links as a separate query path rather than part of the same recursive traversal, or
3. Allow an optional additional_project_ids parameter to find_related() that widens the lookup scope for known cross-project references

[sourrris]

I’m working on this now. I’ll keep the fix scoped to cross-project graph traversal from explicit relation edges and add regression coverage for project isolation.