修复 AGC 项目写锁残留无法回收与启动失败无诊断

- .agent/project.lock 新增 processStartedAt，PID 存活时核对进程启动身份，身份不一致判定 PID 复用并回收
- 旧锁缺少 processStartedAt 时退回“进程启动时间晚于锁 createdAt 加 5 秒容差”的 PID 复用推断
- 空锁 / 坏锁（崩溃停在 create_new 与落盘之间）宽限期由 600 秒收紧到 30 秒，无法判定持有者存活时仍保持 600 秒
- 新增 StartupLogSlot，配置目录就绪前后都能写 startup.log，startup.*.failed 与启动错误提示不再是死分支
- Windows 启动失败恢复系统消息框并附诊断日志路径，其它平台写 stderr，同一进程只提示一次
- 新增 project_lock_recovery 6 条回归用例：死 PID、空锁宽限、PID 复用时间推断、PID 复用身份不一致、身份一致不抢锁、新鲜空锁不抢锁
- 同步 decision-log 与 App 实施计划文档

docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md

@@ -1330,3 +1330,9 @@ DirectProject 使用 `approvalPolicy=never`，避免每次原生调用再经过
 
 - `/api/llm/responses` 与 `/api/llm/chat/completions` 的正式请求体上限为 `32 MiB`。两个路由必须显式配置 Axum `DefaultBodyLimit::max(LLM_REQUEST_MAX_BODY_BYTES)`；不能依赖 handler 内的 `Bytes / Json` 后置检查，否则 Axum 默认 `2 MiB` 会先拒绝 Direct Codex 携带图片工具结果的大上下文请求。超过 `32 MiB` 仍返回 `413 PAYLOAD_TOO_LARGE`。
 - Codex app-server 的 failed turn 需要把上游 / 连接层 HTTP 413、`PAYLOAD_TOO_LARGE` 和 provider proxy 的 `provider request too large` 映射为稳定分类 `codex-app-server-error:request-too-large`；用户可见文案固定为“模型请求体过大，请减少参考图或上下文后重试”，不得落入 `other` 或泛化成权限 / 安全策略错误。
+
+## 2026-09-09 项目写锁残留回收与启动诊断
+
+- `.agent/project.lock` 新增 `processStartedAt`（持有进程启动时间，Unix 秒）。PID 仍存活时必须先核对启动身份：身份不一致即判定 PID 复用，可直接回收；旧锁没有该字段时退回“进程启动时间晚于锁 `createdAt` 加 5 秒容差”的推断。崩溃停在 `create_new` 与落盘 payload 之间的空锁 / 坏锁宽限期从 600 秒收紧到 30 秒；无法判定持有者是否存活时继续按 600 秒保守回收，活持有者仍然不回收。
+- 启动诊断日志改为 `StartupLogSlot`：`configure_game_creator_runtime_config_dir` 之前按应用标识符推导 APPDATA 路径，成功后再切换到真实配置目录，`startup.*.failed` 与 `show_startup_error_dialog` 不再是死分支。Windows 启动失败恢复系统消息框并附诊断日志路径，其它平台写 stderr，同一进程只提示一次。
+- 边界与验证：残留的 `agent-runner.lock` / `agent-runner.gui-owner.lock` 是 OS 独占句柄锁，进程退出即释放，文件本身不阻塞下次启动；真正阻塞启动的是仍有活进程持锁。验证覆盖 `project_lock_recovery` 6 条（死 PID、空锁宽限、PID 复用时间推断、PID 复用身份不一致、身份一致不抢锁、新鲜空锁不抢锁）、`diagnostic_log` 5 条，以及真实二进制双实例：第二个实例写入 `startup.runner.owner-lock.failed` 并弹出可见提示。