[Doc] Better documentation on the rename PR for ember cluster conversions (project-chip#43580)

* Doc clarity on rename PR

* Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Author: andy31415

docs/guides/migrating_ember_cluster_to_code_driven.md

@@ -19,16 +19,44 @@ smaller pull requests. This approach significantly simplifies the review
 process, allowing reviewers to approve preliminary changes quickly. We recommend
 the following sequence of PRs:
 
--   [ ] **PR 1: File Renames Only.**
+-   [ ] **PR 1: File Renames and Moves Only.**
 
     -   If your migration involves renaming files, submit a PR containing _only_
-        the renames. A typical rename is from `<name>-server.cpp` to
-        `<Name>Cluster.cpp`.
-    -   **Note:** For backward compatibility with code generation, it is often
-        best to **not** rename the header file.
+        the renames and file moves. This helps to isolate structural changes
+        from logic changes, making the review process easier.
+
+    -   **`.cpp` file rename:**
+
+        -   Rename `<name>-server.cpp` to `<Name>Cluster.cpp`. This is often a
+            good starting point as much of the implementation can be reused.
+            Renaming allows `git diff` to track changes more effectively than a
+            delete/add operation.
+
+    -   **`.h` file renames and refactoring:**
+
+        -   The legacy header (`<name>-server.h`) often contains a mix of legacy
+            API functions, delegate classes, and other definitions. To maintain
+            backward compatibility while moving to a code-driven model, we
+            recommend the following:
+        -   Create a new `CodegenIntegration.h` header and move the
+            implementation portions of `<name>-server.h` into it. This new file
+            will be responsible for maintaining the legacy API integration logic
+            that interacts with the generated code.
+        -   If `<name>-server.h` contains delegate classes or other distinct
+            components (e.g., `class FooDelegate`), move them into their own
+            header files (e.g., `FooDelegate.h`). A good rule of thumb is that
+            `class Bar` should live in `Bar.h`.
+        -   After moving the implementation out of `<name>-server.h`, update
+            `<name>-server.h` itself to be a wrapper that simply includes the
+            new headers (`CodegenIntegration.h`, `FooDelegate.h`, etc.). This
+            preserves the include paths for existing code while allowing the
+            implementation to evolve.
+
     -   **Why:** This prevents `git diff` from becoming confused and showing the
         entire file as deleted and recreated, making the actual code changes
-        impossible to review.
+        impossible to review. Separating file moves from logic changes is a
+        critical step for an efficient code review.
+
     -   _This type of PR can be reviewed and merged very quickly._
 
 -   [ ] **PR 2: Code Movement Only.**