[FEATURE] Let an existing Cowork session be assigned/moved to a project (API silently ignores chat_project_id on PUT)

A chat conversation can be moved between projects: `PUT /api/organizations/{org}/chat_conversations/{uuid}` with `{"project_uuid": …}` returns 202 and the change reads back.

There is no equivalent for a Cowork/Code session. `PUT /v1/code/sessions/{cse_id}` accepts `chat_project_id`, `chat_project_uuid` and `project_uuid` and returns **200 in every case while the field stays null** — a silent no-op, which is worse than a 400. `POST /v1/code/sessions/{id}/project` and `/move` are 404, and `PATCH|PUT /api/organizations/{org}/cowork/sessions/{id}` and `.../code/sessions/{id}` are 404.

Result: a session that was started outside a project (including trigger-spawned relay runs) can never be filed, so an account that organises everything by project keeps a permanent unfileable remainder — 15 sessions on this account.

Asks, in order of preference:
1. Allow the project to be set on an existing session (API + a "Move to project" control in the UI, matching chats).
2. Failing that, reject an unsupported field with 400 instead of returning 200 and dropping it.

Related: #80061 (project assignment cosmetic), #86611 (project grouping).

Start by tracing the PUT /v1/code/sessions/{cse_id} handling and compare it with the working chat-conversation project update. Confirm how project_uuid and related fields are persisted, then inspect the corresponding UI flow. Done means an existing session can be moved and read back under the project, with a UI control; otherwise unsupported fields must return 400.

Written by the indexing model from the issue text.