docs: update EM full-direction phase 02 blocker

docs/superpowers/handoffs/em-full-direction-visualization/phase-02.md

@@ -87,3 +87,18 @@
 ```powershell
 dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- em-core-all
 ```
+
+## 第二次恢复续行记录
+
+用户随后明确授权修改 `EmPlanningServiceChecks.cs`。该夹具已将纵向 QP 识别从 `VariableCount > 100` 改为布局结构判定（`4N-1` 变量及至少 `8N-2` 约束），从而不再把短完整段的纵向问题误判为横向问题。
+
+在该修复后，真实问题暴露出来：
+
+1. `FullDirectionSegmentScheduleBuilder` 最初在到达 `s_end/v=0` 时立即结束。为满足 Task 3 的零速保持与现有 exact-stop 稳定尾，已在该 schedule 后追加以 `MaximumOptimizationTimeStepSeconds` 切分的 `ZeroSpeedHoldSeconds` 零速 knot。
+2. 该改动后，`longitudinal-model` 与 `longitudinal-integration` 都返回退出码 0；`em-core-all` 已通过 `trajectory`。
+3. 但 full-scope 服务回归仍失败。脚本求解器返回的现有 `CreateExactStopSeed` warm start 在自适应时间 knot 上违反实际 PathS 速度包络（例如 `S=0.006326835275506704, U=0.0328891548874453, limit=0.030034851566717233`）。
+4. 为排除脚本夹具，full-scope 测试临时改用真实 OSQP：追加 hold 前它报告 infeasible；追加 hold 后在默认服务夹具预算内达到 `maximum iterations reached`（4000 iterations，primal residual `0.00018704349099181022`）。因此不能将问题归因于夹具。
+
+这说明阶段 02 的 schedule 消费路径尚未完成：`SequentialLongitudinalOptimizer.CreateExactStopSeed` 仍按旧的固定网格 seed 假设生成候选，未能生成与自适应 `input.KnotSchedule` 和实际 PathS 速度包络同时严格一致的 exact-stop seed。继续通过调整 fixture、增大 knot 数、放宽资源上限、回退滚动模式或改变阶段 03 静止起步逻辑都不安全且不符合计划。
+
+恢复前需要对 seed 策略作出明确技术决定：允许阶段 02 在其已授权的 `SequentialLongitudinalOptimizer.cs`、`LongitudinalConstraintBuilder.cs`、`LongitudinalSolutionValidator.cs` 和允许测试文件内，设计并实现一个由 `input.KnotSchedule.ReferencePathS/ReferenceSpeedMetersPerSecond` 驱动、严格满足动态/速度包络/终端稳定尾的 full-scope exact-stop 初始候选；或由用户批准替代的等价最小策略。恢复窗口必须只处理该策略，不得进入阶段 03。