fix: apply the review items for #680 at merge

Restore settings.json (caseOrder, lastUsedCase) when linked-cases.json cannot be written, with the rollback test extended
List Claude Code's per-project ~/.claude.json entry as not migrated in Core-Concepts.md and CLAUDE.md
Say in the 500 that the folder is now at the new path when moving it back fails
Describe the rename dialog's folder checkbox in Core-Concepts.md, carry stoppedSessions on errors, count 5 case SSE events

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/api-reference.md

@@ -1135,7 +1135,7 @@ A local case whose folder is the top of a git repository can keep **worktrees**
 
 A non-admin's `POST /api/quick-start` and `POST /api/ralph-loop/start` work as before but do not record their case as `lastUsedCase` (a server-wide key).
 
-`POST /api/cases/:name/rename` renames a case. A case under the cases directory is its folder, so it always moves; a linked case renames its alias in `linked-cases.json` and moves its real folder (next to the old one, named `newName`) only with `renameFolder: true`. Remote and Docker cases are `400`. The new name must be free in every namespace the list merges (`409`). Live sessions whose working directory is at or inside the folder that would move make it `409` with `requiresStop: true` and `sessions: [{ id, name }]`; retry with `stopSessions: true` to end them first (nothing is restarted); another user's session is `403`. The folder is held by an in-process lock for the whole operation (an overlapping rename is `409 BUSY`, and `new Session` refuses a working directory inside it), the move is retried for a transient `EBUSY`/`EPERM`/`EACCES` and then answers `423` with `renameCode: "LOCKED"`, a cross-device move is `400`, and if the registries cannot be written afterwards the folder is moved back. On success the response is `{ oldName, newName, oldPath, newPath, folderMoved, stoppedSessions }`; `caseOrder`, `lastUsedCase`, `linked-cases.json` and Claude Code's `projects/<path>` history are updated, and `case:renamed` is broadcast. A linked case is admin only in multi-user mode.
+`POST /api/cases/:name/rename` renames a case. A case under the cases directory is its folder, so it always moves; a linked case renames its alias in `linked-cases.json` and moves its real folder (next to the old one, named `newName`) only with `renameFolder: true`. Remote and Docker cases are `400`. The new name must be free in every namespace the list merges (`409`). Live sessions whose working directory is at or inside the folder that would move make it `409` with `requiresStop: true` and `sessions: [{ id, name }]`; retry with `stopSessions: true` to end them first (nothing is restarted); another user's session is `403`. The folder is held by an in-process lock for the whole operation (an overlapping rename is `409 BUSY`, and `new Session` refuses a working directory inside it), the move is retried for a transient `EBUSY`/`EPERM`/`EACCES` and then answers `423` with `renameCode: "LOCKED"`, a cross-device move is `400`, and if the registries cannot be written afterwards `settings.json` and the folder are put back (when the folder cannot be moved back, the `500` says it is now at the new path). An error from the rename itself carries `stoppedSessions`: how many sessions it ended before it failed. On success the response is `{ oldName, newName, oldPath, newPath, folderMoved, stoppedSessions }`; `caseOrder`, `lastUsedCase`, `linked-cases.json` and Claude Code's `projects/<path>` history are updated, and `case:renamed` is broadcast. A linked case is admin only in multi-user mode.
 
 ### System operations
 

docs/wiki/Core-Concepts.md

@@ -33,9 +33,9 @@ registration, and for a linked case that is all it removes.
 
 **Renaming a case.** In the case manager (Settings, or the case picker's manage view) the pencil
 button renames a case and its folder. A case under `~/codeman-cases` _is_ its folder name, so it
-always moves. A linked case renames its name in the list only; Codeman then asks whether to rename
-the real folder as well, next to where it is (Cancel leaves the folder alone). Remote and Docker
-cases cannot be renamed. Renaming does the following for you:
+always moves. A linked case renames its name in the list only, unless you tick **Also rename the
+folder on disk** in the rename dialog: then its real folder is renamed too, next to where it is.
+Remote and Docker cases cannot be renamed. Renaming does the following for you:
 
 - **Sessions are never moved from under you.** If live sessions have the folder open, the rename is
   refused and lists them; you can then choose to stop them (nothing is restarted). While a rename runs,
@@ -49,8 +49,10 @@ cases cannot be renamed. Renaming does the following for you:
   Resume list uses the renamed folder too, and the case's default session group follows the new name.
 - **Not migrated.** Scheduled (cron) jobs keep the old `workingDir` and fail at their next run until you
   edit them; Claude history of sessions started in a subfolder (including `.claude/worktrees/<name>`)
-  stays under the old path. In multi-user mode only an admin's rename updates the shared case order and
-  last used case.
+  stays under the old path. Claude Code's own per-project settings in `~/.claude.json` (local-scope MCP
+  servers, allowed tools, the folder's trust) are keyed by the old path too, so the renamed case starts
+  without them: Codeman does not write another CLI's configuration here. In multi-user mode only an
+  admin's rename updates the shared case order and last used case.
 - **The case order, the last used case and this browser's per-case options follow the new name.**
 
 **Clone Repo never asks for credentials.** It uses whatever the server's own git already has: