Forked chat/thread becomes inaccessible after leaving session #150

Summary

Forking a chat/thread appears to create and open a new fork successfully, but after navigating away from the chat it is not accessible again from KittyLitter/Litter.

Observed behavior

• Tap the chat/thread Fork action.
• Litter creates a new # thread/code for the fork and opens it.
• A follow-up message can be sent in the forked chat.
• After leaving the chat/session, the forked chat cannot be found or reopened in KittyLitter/Litter.

Environments where reproduced

• Local iPhone / "This Device" environment.
• VM environment.

Because this reproduces in both local iPhone and VM env, it seems less likely to be a single local runtime issue and more likely that forked threads are created/opened but not persisted, indexed, rehydrated, or surfaced back into the Sessions list after navigation.

Expected behavior

A forked chat/thread should remain accessible after leaving the conversation, ideally appearing in Sessions and/or under the Forks filter with enough title/timestamp metadata to distinguish it from the parent thread.

Notes

The current iOS flow appears to call forkThread(...), set the returned key as active, refresh the new thread snapshot, and open it. That part seems to work initially. The failure appears to happen later when trying to rediscover/reopen the forked thread from Litter after leaving the chat.

Suggested areas to inspect:

• Whether the forked thread is persisted by the local/VM backend after creation.
• Whether thread list/session list APIs include forked threads after thread/fork.
• Whether Sessions screen filtering/grouping hides forked threads by default.
• Whether forked threads inherit duplicate titles and are effectively indistinguishable from parent threads.

User impact

The Fork feature is risky to use because follow-up work in the fork can become inaccessible once the user leaves the chat.