[Bug] Resume picker and kimi session list show no sessions when a stray file sits in a sessions bucket directory #3500

Summary

On 0.40.x, the resume picker (kimi -r, /sessions) and kimi session list fail to list any sessions when any workspace bucket directory under ~/.kimi-code/sessions/ contains a stray regular file. On macOS, Finder's .DS_Store inside a bucket directory is enough to trigger it — kimi session list prints storage stat failed: unrecognized I/O error, and the TUI picker swallows the error and shows "No sessions found".

Reproduction

1. touch ~/.kimi-code/sessions/wd_example_000000000000/.DS_Store (or just browse that folder in Finder once)
2. Run kimi session list in any project → storage stat failed: unrecognized I/O error
3. Run kimi -r → the picker shows no sessions

Root cause

#3422 (0.40.0) added mtime probes to the session index: scanAuthoritative / scanSessionsMaxMtime stat <entry>/state.json and <entry>/session-meta/state.json for every entry of every bucket directory. When an entry is a regular file, that stat fails with ENOTDIR. FileStorageService.mtime only tolerates ENOENT and translates every other errno into StorageError(storage.io_failed) ("unrecognized I/O error"), so the entire scan rejects — projection, startup freshness checks, periodic reconciliation, and the authoritative fallback read path all fail, and no session can be listed at all.

A long-running server degrades into a per-entry-tolerant legacy read branch, so an already-running web/desktop UI keeps showing sessions, while any fresh process (TUI resume picker, kimi session list) reads through sharedScanForRead() and hits the throw — which makes it look like different frontends see different session sets.

Environment

kimi-code 0.40.1, macOS 26 (reproducible on any platform where a bucket directory can hold a non-directory entry).