fix(api): show user-scope memories in /api/memories listing

[leiverkus]

Summary

handleListMemories without a tag filter only walks project-scope shards and discards any row whose container_tag doesn't include the literal substring _project_. User-scope memories — canonical tag format opencode_user_<sha16> — are therefore structurally invisible from this endpoint, even though they store and search correctly.

The result is a confusing UX:

Endpoint	Sees user-scope memories?
POST /api/memories (writing them)	✅
GET /api/search	✅
GET /api/stats (byScope.user and byType)	✅
GET /api/memories (listing)	❌
Web UI navigation (built on /api/memories)	❌

Reproduction (against current main, v2.15.0)

# Write a user-scope memory
curl -sS -X POST http://127.0.0.1:4747/api/memories \
  -H "Content-Type: application/json" \
  -d '{"content": "test fact", "containerTag": "opencode_user_64feb0e31e5b9625", "type": "fact"}'
# → { "success": true, "data": { "id": "mem_..." } }

# Stats knows it's there
curl -sS http://127.0.0.1:4747/api/stats
# → { "byScope": { "user": 1, "project": 0 }, "byType": { "fact": 1 } }

# Search finds it
curl -sS "http://127.0.0.1:4747/api/search?q=test"
# → { "data": { "items": [ { "id": "mem_...", "content": "test fact" } ] } }

# Listing silently hides it
curl -sS "http://127.0.0.1:4747/api/memories"
# → { "data": { "items": [], "total": 0 } }     ← BUG

Root cause

src/services/api-handlers.ts:161-167:

} else {
  const shards = shardManager.getAllShards("project", "");      // ← only project shards
  for (const shard of shards) {
    const db = connectionManager.getConnection(shard.dbPath);
    const memories = vectorSearch.getAllMemories(db);
    allMemories.push(...memories.filter(
      (m: any) => m.container_tag?.includes(`_project_`)         // ← only project tags
    ));
  }
}

Two parallel filters: shard scope is hardcoded "project", and the row filter only keeps _project_ tags. Both have to be widened.

handleStats at line 742-743 was already correct (counts both _user_ and _project_), so this PR just brings the listing endpoint into agreement with what stats reports.

Fix

Iterate both project- and user-scope shards in the no-tag path, widen the defense-in-depth filter to match both canonical scope markers. The tagged path (when tag is provided) is unchanged because extractScopeFromTag already resolves the requested scope correctly.

Out of scope

handleListTags (line 105) is intentionally project-only by its return-shape contract ({ project: TagInfo[] }). Exposing user-scope tags there would be a contract-breaking change to the response shape, which doesn't fit a small UX fix. Happy to do that as a follow-up if you want — could either add a user key to the response or split into /api/tags/project + /api/tags/user.

Verification

• bun test: 143 pass / 0 fail (no regressions)
• bun run typecheck: clean
• bun run build: clean
• npx prettier --check: clean
• Manually reproduced the bug on v2.15.0, applied this patch, confirmed all four endpoints now agree about what exists.

Environment

• macOS 26.3 (Apple Silicon, arm64)
• opencode 1.15.10 CLI + 1.15.13 Desktop (anomalyco fork, Node sidecar)
• opencode-mem 2.15.0 + PR fix(sqlite): shim db.transaction(fn) on node:sqlite DatabaseSync #123 transaction-shim applied locally
• Node 26.0.0