Allow stored Codex threads to be associated with a project cwd after planning

Proposal

Please consider adding a supported way to update a stored Codex thread's project or workspace association after the thread has already been created. One small backend primitive for this would be allowing stored thread metadata updates to patch the thread cwd.

Motivation

A common workflow is to start with early planning in a standalone Codex conversation before the repository or project directory exists. After the project folder is created, the useful planning context can remain outside the project/workspace it now belongs to.

Today, the practical workaround is to ask Codex to generate context files and write them into the new repository. That helps, but it still leaves the original conversation detached from the workspace. A supported metadata update would make it possible for clients to build a more natural "attach", "move", or "promote this thread to a project" flow without touching local sqlite state directly.

Possible implementation direction

The thread model already persists cwd, and thread/list already supports cwd-based filtering. The existing thread/metadata/update method also patches sqlite-backed thread metadata for gitInfo.

One narrow approach would be to extend thread/metadata/update with an optional cwd field, resolve it consistently with existing cwd handling, and persist it through the existing thread metadata patch path.

Benefits

• Preserves planning context when a project is created after the initial conversation.
• Avoids direct client-side edits to local sqlite state.
• Gives Codex clients a small backend primitive for future UI workflows that attach or move a thread into a workspace.
• Keeps the behavior scoped to metadata rather than changing thread contents or replaying conversation history.

I understand that external code contributions are by invitation only. I am happy to keep this as a design discussion unless the Codex team thinks a small PR would be useful.