docs: sync rendering request, surface, and binding docs

docs/api/XCEngine/Rendering/SceneRenderRequestPlanner/SceneRenderRequestPlanner.md

@@ -11,9 +11,15 @@
 ## 概览
 
 `SceneRenderRequestPlanner` 处在 [SceneRenderer](../SceneRenderer/SceneRenderer.md) 和 [SceneRenderRequestUtils](../SceneRenderRequestUtils/SceneRenderRequestUtils.md) 之间。
-
 它不亲自渲染任何东西，而是把“应该渲染哪些相机、按什么顺序、哪些请求应该被丢弃”整理成一组 [CameraRenderRequest](../CameraRenderRequest/CameraRenderRequest.md)。
 
+这种“先规划 request，再执行 request”的拆法很接近商业引擎里常见的 camera scheduling 思路。它的价值不是抽象更漂亮，而是把两类会频繁变化的逻辑拆开：
+
+- 场景侧规则：相机收集、stack/depth 排序、clear 推导、viewport 解析
+- 执行侧规则：scene extraction、主管线、object-id、post/overlay pass
+
+这样 Editor、离屏渲染和手工 request 注入都能复用同一套规划规则，而不用直接碰 `CameraRenderer` 内部执行链。
+
 ## 公开方法
 
 | 方法 | 说明 |
@@ -40,9 +46,21 @@
 - 已成功生成的 request 数量
 
 这两个计数会影响自动 clear flag 的推导。
-
 如果某个相机最终解析出的 render area 宽高为 `0`，该请求会被直接丢弃，而且不会错误地推进 base camera 计数。
 
+## 设计取舍
+
+当前 planner 故意保持“只做一件事”：
+
+- 负责决定 request 集合
+- 不负责 request 执行
+- 不负责附加 pass 组装
+
+这是一种比很多早期引擎实现更稳的做法。否则 Scene View 一旦要加 object-id、grid、selection outline、editor overlay，规划逻辑和执行逻辑很容易在一个类里互相缠死。
+
+另一个重要取舍是：当前只支持 base / overlay + depth 的线性排序，而不是更复杂的 stacking 依赖图。
+这不是文档漏写，而是当前实现的真实边界。它优先保证顺序简单、稳定、可测试。
+
 ## 真实使用位置
 
 - `engine/include/XCEngine/Rendering/SceneRenderer.h` 持有一个 `SceneRenderRequestPlanner` 实例。
@@ -63,3 +81,4 @@
 - [SceneRenderer](../SceneRenderer/SceneRenderer.md)
 - [SceneRenderRequestUtils](../SceneRenderRequestUtils/SceneRenderRequestUtils.md)
 - [CameraRenderRequest](../CameraRenderRequest/CameraRenderRequest.md)
+- [Camera Request Planning And Clear Rules](../../../_guides/Rendering/Camera-Request-Planning-And-Clear-Rules.md)