[Bug] Archived projectless threads are grouped as projects by cwd basename

Summary

In the Codex Desktop Archived Conversations view, archived threads that were created from arbitrary working directories are displayed under project-style folder groups named after the final component of their cwd, even though those directories were never added as Codex projects.

This makes projectless threads look as if they belong to saved projects.

Environment

• Codex Desktop: 26.707.91948
• macOS: 26.5.2 (25F84)
• Architecture: Apple Silicon (arm64)
• Thread source: vscode

Steps to reproduce

1. Open a folder in VS Code, for example:

• /Users/<user>/Documents/Codex/<date>/mu

1. Start a Codex thread from that folder without adding the folder as a saved Codex project.
2. Repeat from another arbitrary folder, for example .../dan.
3. Archive both threads.
4. Open Archived Conversations in Codex Desktop.

Actual behavior

The archived view creates project-style groups with folder icons:

• mu
• dan

Each group contains the thread created with that working directory.

However, mu and dan do not appear in the current saved project list and were never intended to be projects.

Local diagnostics confirm:

• both threads have source=vscode
• both have thread_source=user
• their stored cwd values end in /mu and /dan
• neither path is present in the Codex saved-project list

This suggests the archived view groups threads using the basename of cwd without first checking whether the path corresponds to a saved project.

Expected behavior

Archived threads should be grouped as follows:

• If the thread is associated with a saved project root, show it under that project.
• If its working directory does not match any saved project, show it in a shared Projectless, Chats, or Other conversations section.
• An arbitrary directory basename should not be presented with a project folder icon.

Why this matters

The current UI conflates a working directory with a saved project. It creates project groups that do not exist elsewhere in Codex and makes users think thread/project metadata changed during archiving.

Additional note

The archived view displays the thread's last-updated time correctly. The problem is specifically the folder grouping and project-like presentation, not thread loss or timestamp handling.