fix(relations): only set targetProjectSlug for genuine cross-project edges

The previous commit always populated targetProjectSlug from the
target's project_id, but for workspace projects the source-side
StoreManager is bound to the synthetic workspace-root project (e.g.
slug 'backend'), and that root is not exposed as a navigable project
in the multi-config — only its real members like 'api-gateway' and
'catalog-service' are. So workspace-shared knowledge → knowledge edges
were emitting targetProjectSlug='backend', the UI tried to navigate
to /ui/backend/knowledge/X, and the REST layer rejected it with
"Project 'backend' not found".

Fix: skip resolution when targetProjectId equals the current scoped
project. The UI then falls back to whichever real project is already
in the URL. Cross-project resolution only kicks in when the target
genuinely lives in a different project (workspace knowledge → code/
docs/files in a specific subproject).

Verified end-to-end against the real demo workspace database:

  Note 25 (workspace knowledge):
    out implemented_in → code   "rate-limiter.ts"   project: api-gateway
    out documented_in → docs    "Rate Limiting"     project: api-gateway
    in  relates_to    → knowledge "API Versioning Strategy" project: (current)
    in  implements    → tasks   "..."               project: (current)

  Note 28:
    out implemented_in → code   "search-service.ts" project: catalog-service
    out documented_in → docs    "Search Algorithm"  project: catalog-service
    out depends_on    → knowledge "..."             project: (current)

Author: prih

src/lib/store-manager.ts

@@ -584,10 +584,18 @@ export class StoreManager {
     for (const [g, ids] of idsByGraph) {
       titles.set(g, this.scoped.resolveTitles(g, ids));
     }
-    // Resolve project ids → slugs (batched via small in-memory cache).
+    // Resolve project ids → slugs only when the target lives in a *different*
+    // project than the current scoped store. Same-project (including workspace-
+    // shared graphs where every node has project_id = workspace root) leaves
+    // targetProjectSlug undefined so the UI falls back to whatever project is
+    // already in the URL — that's important because the synthetic workspace
+    // root project (e.g. slug 'backend') is not a navigable project in the
+    // multi-config: only its real members like 'api-gateway' / 'catalog-service'
+    // are exposed.
+    const currentProjectId = this.scoped.projectId;
     const projectSlugCache = new Map<number, string | undefined>();
-    const resolveProjectSlug = (id: number | undefined): string | undefined => {
-      if (id === undefined) return undefined;
+    const resolveTargetProjectSlug = (id: number | undefined): string | undefined => {
+      if (id === undefined || id === currentProjectId) return undefined;
       if (projectSlugCache.has(id)) return projectSlugCache.get(id);
       const slug = this.store.projects.get(id)?.slug;
       projectSlugCache.set(id, slug);
@@ -597,7 +605,7 @@ export class StoreManager {
       ...v.edge,
       targetGraph: v.targetGraph,
       targetId: v.targetId,
-      targetProjectSlug: resolveProjectSlug(v.targetProjectId),
+      targetProjectSlug: resolveTargetProjectSlug(v.targetProjectId),
       title: titles.get(v.targetGraph)?.get(v.targetId) ?? String(v.targetId),
       direction: v.direction,
     }));

src/tests/store/store-manager.test.ts

@@ -605,27 +605,27 @@ describe('StoreManager', () => {
       expect(titles.get(tagEdge!.fromId)).toBe('gamma');
     });
 
-    it('populates targetProjectSlug from edge fromProjectId/toProjectId', async () => {
-      // The current test setup has a single project, so we synthesize the
-      // cross-project case by injecting raw Edge objects with explicit
-      // fromProjectId/toProjectId. This mirrors how the workspace scenario
-      // works in real life: shared knowledge → project-scoped code/docs/files.
-      const note = await manager.createNote({ title: 'Cross-project source', content: '' });
+    it('leaves targetProjectSlug undefined when target lives in the current project', async () => {
+      // Same-project edges should not surface a targetProjectSlug. The UI
+      // falls back to the project already in the URL, so workspace-shared
+      // knowledge (where every node lives under the synthetic workspace-root
+      // project) keeps navigating through whichever real project the user is
+      // currently viewing.
+      const note = await manager.createNote({ title: 'Source', content: '' });
       const fakeOutgoing = {
-        fromGraph: 'knowledge' as const, fromId: note.id, fromProjectId: 1,
-        toGraph: 'code' as const, toId: 999, toProjectId: 1,
-        kind: 'implemented_in',
+        fromGraph: 'knowledge' as const, fromId: note.id, fromProjectId: manager.projectId,
+        toGraph: 'knowledge' as const, toId: 999, toProjectId: manager.projectId,
+        kind: 'relates_to',
       };
       const fakeIncoming = {
-        fromGraph: 'tasks' as const, fromId: 888, fromProjectId: 1,
-        toGraph: 'knowledge' as const, toId: note.id, toProjectId: 1,
+        fromGraph: 'tasks' as const, fromId: 888, fromProjectId: manager.projectId,
+        toGraph: 'knowledge' as const, toId: note.id, toProjectId: manager.projectId,
         kind: 'documents',
       };
       const enriched = manager.enrichRelations('knowledge', note.id, [fakeOutgoing, fakeIncoming]);
       expect(enriched).toHaveLength(2);
-      // Project id 1 was created in beforeEach with slug 'test'.
-      expect(enriched[0].targetProjectSlug).toBe('test');
-      expect(enriched[1].targetProjectSlug).toBe('test');
+      expect(enriched[0].targetProjectSlug).toBeUndefined();
+      expect(enriched[1].targetProjectSlug).toBeUndefined();
     });
 
     it('createEdge stores correct to_project_id for cross-project targets', async () => {