fix(responses): resolve project only when creating a conversation (ENG-1028)

[tino097]

Summary

Fixes the server half of ENG-1028: after a project rename, chat turns failed with Project not found: <name>.

ResponsesHandler.handle() resolved the client-sent project name eagerly on every request — but the renderer holds that name in long-lived state, so after a rename the wire carries a stale name. For an existing conversation the name is redundant (the conversation already pins its project via conversation.project_id), yet the eager resolve hard-404ed every later turn of the task.

Server-side rename itself was verified correct (service- and API-level, local + org modes) — the 404 was purely the eager resolution of a redundant stale name.

Changes

• _resolve_project_id is now called only at the three create_conversation sites; turns on existing conversations never depend on the client-held name.
• Creating a NEW conversation with an unknown project name still 404s (contract preserved).
• New tests in tests/test_responses_project_rename.py: rename→resolve pin, existing-conversation-with-stale-name survives (red before this fix), unknown-name-on-create still 404s, new chat in a renamed project resolves the new name.

Tests

• uv run pytest tests/test_responses_project_rename.py — 4 passed
• Full suite: 671 passed, 1 failed (test_comments_layer.py::test_serve_injects_only_with_flag) — verified pre-existing on the staging baseline (fails with this change stashed).

Companion renderer PR (mindsdb/cowork): sends the rename-proof project_id and re-anchors selectedProject on rename. Independently safe to merge; server side first is preferred.

🤖 Generated with Claude Code

[github-actions]

No PR environment for this pull request

Add the deploy label and push to create one. It is torn down when the label is removed or the PR closes, so any URL you saw here earlier is gone.

_{Updated on every push to this PR.}