[Manohar Paturi (ManoharPaturi)]

Motivation & Context

MemoryFileStore keyed every topic file by _slugify_topic(topic), which is many to one: C ++ and C # both slug to c. write_topic overwrites the slug path unconditionally, so writing a second topic that shares a slug silently destroyed the first topic's memories. Reproduced on main: after writing both topics, get_topic("C ++") returned the C # memory and the C ++ memory was gone. The store's own path components for owner, session, source, and scope all use the injective _storage_key_segment derivation for exactly this reason; the topic filename was the one mapping left below that standard.

Description & Review Guide

• What are the major changes? The topic filename stem is now the readable slug plus an 8 character digest of the normalized topic, so distinct normalized topics never share a file. Writes path by the record's normalized topic, and reads resolve the digest stem first.
• What is the impact of these changes? Topics that share a slug coexist with their own memories. Reads keep working for stores written before this change through two fallbacks: the legacy slug-only filename, then a slug-prefix scan that also serves lookups made by slug (several tests look topics up by record.slug). When a slug-only lookup is ambiguous because several topics share that slug, the file whose recorded topic matches the lookup wins, else the first stem in sorted order keeps the choice deterministic.
• What do you want reviewers to focus on? The fallback chain in _existing_topic_path, and the regression test writing C ++ then C # and reading both back, which fails on main.

Related Issue

Fixes #9723

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.