[Bug] Removing session_projcache (documented as a non-authoritative cache) makes every session disappear from the sidebar ("No sessions yet")

[Max6617]

Summary

@deepseek-ai/dsh-session-projection-cache documents itself as "a fold shortcut, never an authority". But if ~/.dsh/storages/session_projcache/ is empty or missing, the Desktop sidebar shows "No sessions yet" and no workspaces at all, even though every session is still intact under ~/.dsh/sessions/. Putting the matching cache records back brings the sessions back. So in practice the cache is authoritative for the session list.

Environment

• DeepSeek Harness Desktop 0.2.0-rc.2 (nightly), Electron 44.0.0, Node 24.18.1
• Windows 11 Home (build 26300), x64

Steps to reproduce

1. Have some sessions (I had 689 sessions across 49 workspace folders under ~/.dsh/sessions).
2. Quit the app and move ~/.dsh/storages/session_projcache somewhere else.
3. Start the app.
   • Actual: the sidebar says "No sessions yet", the Workspaces list is empty, and the composer says "Choose a workspace to start". After several minutes the cache directory still hasn't been recreated.
   • Expected: sessions are listed (possibly without cached titles or previews), and the cache gets rebuilt in the background.
4. Quit the app, copy back only the session-<id>.json records matching existing sessions, and start again. All workspaces and sessions show up again.

Why this matters

• It turns "delete the cache" into apparent data loss. Users who clear caches to fix problems (or who follow the module's own docs) will think their history is gone.
• It makes the EMFILE startup problem ([Bug] Desktop (Windows): per-record storage loads every record file at once → EMFILE during Host startup (14k session_projcache files) #9609) harder to recover from: removing the oversized cache fixes the startup but hides everything.

Suggested fixes

1. Build the session list from the session store / headers. Use the projection cache only to add titles and previews, as the docstring describes (cachedSnapshot() returning undefined should mean "no preview", not "no session").
2. Rebuild missing cache rows lazily or in the background when a session is listed with no cache record.
3. If the cache can't be read, show a notice ("Session index is rebuilding…") instead of an empty-state screen.

[xiaoshenming]

一条佐证，说明这个「名义上非权威、实际是权威」的落差已经在外面造成了影响。

我们这边有一份第三方修复工具（dsh-session-surgeon），它处理 #8812 那个空闲修剪器尾巴时的指引里写着：如果修完以后界面还显示被修剪掉的旧文本，就删掉那条会话的 <home>/storages/session_projcache*/sessions/<id>.json 让它重建。这条指引来自报告者的现场实测，我们照抄进了 CHANGELOG 和文档 —— 也就是「按模块自己的文档，缓存可以随便清」这条假设被下游当成了事实。看到你这帖之后我们把它改成了移走、不要删（移走的记录能拷回来，删掉的未必），并把你这帖的数字记进了 REPAIR-SPEC：整份缓存缺失时 689 个会话的日志一份没少，侧边栏却是空的。所以这不止是「清缓存的人以为自己丢了数据」，而是别人写的工具会把用户往那个方向推。

关于你建议的第 1 条（列表从会话存储/头部构建），可以给一个现成的证据：会话列表确实只需要头部。我们的 scan / index 就是在不解压整份日志、也完全不碰 session_projcache 的前提下，从每个 session.vN.jsonl.zstd 的第一个 zstd 帧（只有 header 一行）里读出 id / project / parent / depth / preset / turns / goal / 最后一条 turn/end 的 reason 的 —— 所以你列的那些字段本来就在盘上，且是每会话一次小读；缓存只需要负责标题与预览这类可以缺的东西。

另外一个和修复有关的边角：我们故意不对这个缓存下判定（#8010 那个「末尾整帧丢失看不见」的场景里，它是唯一在盘的见证）。三条实测理由都写在 REPAIR-SPEC 里了，其中最要命的一条正是你这条的另一面 —— 缓存落后是合法的（本机 6 份当前代际日志：5 份精确相等、1 份落后 2），而且任何合法把日志改短的路径（我们自己的 seq-gap-committed 就是截断到缺口前最后一个 turn/end）都会让它看起来像丢尾。所以它既不能用来判定日志，也不该被当成可以随手删的派生数据 —— 这两件事是同一个「文档说它非权威」的后果。