Stats endpoint returns zero despite persisted memories after session commit

[SeeYangZhi]

Bug: /api/v1/stats/memories returns zero despite persisted memories

OpenViking version: v0.3.3
Deployment: Docker (openviking/openviking-server-openviking), 19 min uptime
Config: Dev mode, localhost only, no root_api_key, user root:default:default

Steps to Reproduce

1. Start fresh OpenViking instance
2. Create a session and post messages
3. Commit the session (triggers memory extraction)
4. Wait for extraction + vectorization to complete
5. Call GET /api/v1/stats/memories

Expected

Stats endpoint returns the actual memory count (10 extracted memories across preferences, entities, events, and a profile).

Actual

{
  "total_memories": 0,
  "by_category": {
    "profile": 0,
    "preferences": 0,
    "entities": 0,
    "events": 0,
    "cases": 0,
    "patterns": 0,
    "tools": 0,
    "skills": 0
  },
  "hotness_distribution": { "cold": 0, "warm": 0, "hot": 0 },
  "staleness": {
    "not_accessed_7d": 0,
    "not_accessed_30d": 0,
    "oldest_memory_age_days": 0
  }
}

Evidence that Memories Actually Exist

1. Docker logs confirm extraction completed:

   Starting memory extraction from 16 archived messages
   Extracted 10 candidate memories (language=zh-CN)
   Created memory file: viking://user/default/memories/preferences/mem_cf5065ed-723b-4561-b387-d9f769de3f00.md
   Created profile at viking://user/default/memories/profile.md
   ...
   Session 20260407_032824_8f1aae memory extraction completed
   

2. Semantic processing + vectorization completed:

   Vectorized abstract.md and overview.md for viking://user/default/memories/preferences
   Vectorized abstract.md and overview.md for viking://user/default/memories/entities
   Vectorized abstract.md and overview.md for viking://user/default/memories/events
   

3. GET /api/v1/fs/ls?uri=viking://user/default/memories returns the directories (entities, events, preferences).

4. POST /api/v1/search/find returns the memory files with their abstracts (Chinese-language summaries from extraction).

5. GET /api/v1/debug/vector/count returns 18 (includes the original 18 skeleton records + newly vectorized overview/abstract files). Though notably this count didn't increase by 10 either -- it seems to only count top-level overview/abstract files, not individual memory .md files.

Possible Root Cause

The stats endpoint likely reads from a dedicated stats/metadata index that gets populated during synchronous memory write operations (e.g., content/write), but not by the async semantic_processor pipeline that runs after session commit. The memory files are written to the filesystem and vectorized into the search index, but the stats counter is never incremented.

The debug/vector/count returning 18 (unchanged) also suggests that individual memory .md files created by the memory extractor aren't being vectorized individually -- only the directory-level abstract.md and overview.md files are. This could be by design (hierarchical retrieval) or a separate bug.

Impact

Low. Search, browse, and content read all work correctly. Only the stats dashboard/count endpoint is inaccurate.