Fix/session migration

[sjswerdloff]

Summary

This pull request resolves a critical bug that caused sessions to appear lost when the application was launched from a different directory than the one in which the sessions were created. It introduces a global session storage mechanism and a lazy migration strategy to seamlessly transition existing sessions without data loss.

Problem

Previously, session data was stored in a directory scoped to a project.id, which was derived from the current working directory. This meant that if a user started the application in /project-a and created sessions, those sessions would not be visible when the application was later started in /project-a, as a partial migration had already taken place. This gave the impression that the sessions had been deleted, leading to a confusing and frustrating user experience.

The issue was compounded when attempting to interact with a session from a different directory, which would result in an ENOENT: no such file or directory error, as the application would look for the session file in the wrong location.

Solution

This PR implements a robust, backwards-compatible solution by refactoring the session storage logic:

1. Global Session Storage: All new sessions are now created in a centralized session/global/ directory within the application's storage path, removing the dependency on the project's directory.

2. Lazy Migration for Existing Sessions: To handle sessions created before this change, a lazy migration strategy has been implemented in the get, update, and remove functions. When an operation is performed on a session:

   • The system first looks for the session file in the new session/global/ directory.
   • If not found, it searches the old project-specific directory (session/<project_id>/).
   • Upon finding the session in the old location, it is automatically and transparently moved to the new global directory before the operation proceeds.

3. Backwards-Compatible Listing: The list function has been updated to read sessions from both the new global directory and any existing project-specific directories, ensuring that all relevant sessions for the current context are displayed, regardless of where they are stored.

4. Load Last Session on Startup: A client-side improvement was also included to automatically load the most recent session on application startup, improving usability.

This approach ensures that all existing data is preserved and migrated seamlessly over time, while all new data adheres to the more robust global storage model.

Testing

This fix has been manually tested by:

1. Starting the application and creating a new session.
2. Closing the application and restarting it.
3. Verifying that the session created in step 1 is correctly listed and can be opened.
4. Verifying that interacting with the session (sending a prompt) works as expected and does not produce an ENOENT error.
5. Verifying that old sessions created with the previous storage mechanism are also listed and are automatically migrated upon interaction.