fix(runtime): recover Windows lock creation and exact fixture cleanup

[loopx-agent]

Native Windows lifecycle validation failed in the admitted-write lock-contention fixture: exclusive creation returned EPERM, and the admitted journal write failed (current-main job). The existing lock owner now retries this Windows open failure only after observed contention, before a handle has been created, and within the original deadline. Initial/persistent permission denial, post-creation failures, other platforms, zero-wait behavior and token/inode fences remain enforced. Windows documents pending-delete path denial; the trace identifies EPERM/open; its internal open-attempt sequence was not logged, so the pending-delete mechanism remains unproven.

A separate reference-branch failure exposed fixture cleanup racing the 250 ms idle window. Cleanup now stops its recorded locator through the existing authenticated shutdown/OS-exit owner. Serving and already-idle variants reject starting a third process just to shut it down.

Validation:

• Before repair: the lock regression vectors reported 5 passes / 2 expected failures; the decoder cleanup regression reported 1 pass / 1 expected failure.
• Final isolated filesystem tests: 15 passed. Related real File/SQLite, journal and scheduler-state suites: 793 passed, zero skips/failures. Real runtime lifecycle batch with two workers and the production timing plugin: 222 passed, 10 platform skips on macOS; complete JUnit retained locally.
• TypeScript typecheck, Ruff, full semantic vocabulary scan, maintainability ratchet, public-boundary and diff checks passed. The new deadline test initially mixed clock resolutions; its failure is retained and the final oracle uses the same clock as acquisition.
• Exact-head change-quality receipt: cqr_092256bb387baad7ad23 (head ef46fdc835522978be214d9e3517c2eb66b63262). Risk-based premerge: all 4 direct checks and 11 selected checks passed, zero failures/warnings/advisory failures/manual holds; the exact receipt was verified.

Natural hosted validation on the unchanged head:

• The complete native Windows job passed on Windows Server 2025, Python 3.11.9 and Node 24.21.0: lifecycle 213 passed / 19 platform skips, local-state recovery 27 passed, and SQLite CLI 9 passed. Its Node 22.22.3 scheduler/SQLite suites passed 432 tests with zero skips, failures or cancellations. The source frontend rebuild with an unusable python3.exe shadow and final bundle verification also passed.
• The PostgreSQL job passed against a real disposable PostgreSQL 16.15 service, including the conformance ladder and 11 service-admission tests with zero skips/failures.
• The Ubuntu release build passed clean wheel installation, installed HTTP/frontend and sdist rebuild, real packaged Chromium, DSH installation, the release smoke and post-restore package checksums on Python 3.11.17 / Node 24.21.0. PR attestation, public release upload and PyPI publication were skipped.

All three jobs actually checked out 1b790492862505c2274fc56bdad5e5336b4d3c39 (base 369eda5f71a41062636c825b4d9b60f1ecbaf28c plus this head); its complete Git tree equals the authored head. This is one exact-source native Windows qualification, not proof of the original intermittent cause, sustained operation, complete six-shard CI or runner-cost improvement. Full required PR checks, independent exact-head review and maintainer adoption remain separate; no merge, manual hosted rerun or new local test run was performed for this readback. Related refactor pass reused the existing filesystem and shutdown owners; no new capability, configuration, protocol vocabulary or resource policy.

[loopx-agent]

Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; reasoning_effort=max; declaration_source=runtime_reported.

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

精确 head：ef46fdc835522978be214d9e3517c2eb66b63262；基线：369eda5f71a41062636c825b4d9b60f1ecbaf28c。完整 4文件 +119/-12，独立核验整个提案，没有查询或等待 CI。

动机

Windows 上共享状态写入者需要在真实争用后的短暂路径拒绝中恢复，同时保留初始权限错误与原等待上限。

旧实现遇到 EEXIST 后再遇 EPERM 会立即失败；当前只对同次调用已观察争用、尚未成功创建、Windows 的 exclusive-open EPERM，在原 deadline 内重试。测试清理同时改为结束已持有的确切进程，避免退休后 rediscovery 另启第三个进程。

实际生产 filesystem owner、真实句柄/锁文件及 RPC/进程清理路径已验证；原生 Windows 内核行为和原间歇故障根因尚未独立证明。

不改变权限、调度预算、评分、全局错误策略或生产 shutdown owner，不认证长期稳定性。

此处交付有界恢复与可判别的清理回归；Windows 原生平台资格及持续运行仍需保留各自证据，不能从故障注入或成功运行反推根因。

改动思路

重试判断留在现有 TypeScript 文件锁 owner，Python 仅调整该进程测试的清理调用。

当前 PR 边界是争用后 exclusive-open 的有界错误恢复，以及同一个 fixture 所创建进程的精确清理。

输入	结果
Windows，先 EEXIST 再未创建的 EPERM	原 deadline 内重试；恢复后仍验证 token、真实文件身份并按 token 释放
初始 EPERM、其它平台/错误、创建后写失败	继续原失败语义，不获得额外重试权
持续 EPERM	原预算耗尽后抛原 EPERM，不伪装成成功或换成无关错误
零等待、活 owner	不新增一次等待；死 owner 的原有一次 reclaim 机会保留
fixture 已 idle-retired	按原 locator 清理，观察真实退出，不 rediscover 新 runtime

具体改动

关键代码讲解

1. acquireFileMutationLock 用调用内 contended 和每次尝试的 opened 限定重试。不扩大 stale reclaim、PID/token/inode 校验或 deadline；下一目标调用从未争用状态开始。
2. test_runtime_decode_change_rotates_identity_and_starts_replacement 记录 replacement locator，以既有 _stop_effect_runtime(..., wait_for_process_exit=True) 清理，覆盖 serving 与 idle-retired，验证 captures 不增长、两 locator 消失及 OS 退出。这是 fixture 使用原 cleanup owner，不是另造生产 shutdown 协议。
3. effect_runtime_io.test.ts 新增7个边界向量，只注入选定 open/write 错误与平台谓词；句柄、owner、锁内容、release 都运行生产文件系统逻辑。双语 testing-and-quality 补充同一边界与平台限制。

依据变更前 docs/development/testing-and-quality.md 的 Refactor Real-Path Gate / 重构真实路径门 与 Isolate the managed Effect process as well as the data 私有命名空间/真实退出条款，核验真实 owner 与清理，而不把 mock 计数当退出凭据。Microsoft DeleteFileW 说明支持 pending-delete 路径可能拒绝重新创建的机制；这是该分支的合理依据，不能证明历史故障一定由它造成。

对主干的风险

同一当前测试字节运行不可变 base/head 文件系统源：base 2失败13通过，head15通过，均无跳过。两个 base 失败分别是争用后恢复与持续拒绝的有界重试；其余负例通过。额外两个真实目标顺序探针显示前目标恢复用了3次 open，后目标初始 EPERM 仅1次，局部争用状态未泄漏为后续授权。

完整当前 Python lifecycle 93通过、0跳过。相同新清理测试在 base 和 head 都是2通过，说明复用的精确-stop owner 早已可用，不应伪造为生产 base 红绿。另做旧清理策略反事实：只把清理调用换回原 rediscovery，其余当前断言不变，idle-retired 1失败、serving 1通过，退休后 captures 从2变3；当前精确清理避免额外进程。这是清理策略反事实，与前述生产锁的 base/head 配对分别记录。

advisory、完整 semantic/维护性 ratchet、TSC、配置范围 mypy、Ruff、diff 检查通过；premerge 4 direct +11 selected/executed，产品失败0、manual hold0。本地 quality_receipt_missing 是另一个质量资格失败，没有制造回执或忽略；2个提交均 DCO。原生 Windows 没有在本轮执行，也未读取 CI，作者原生运行声明仍是作者证据。持续 EPERM 会占满既有等待预算，这是披露后的恢复成本，没有新 timeout 或无限重试。

没有新增共享状态词汇：OS errno 为既有外部错误，两个布尔状态只属于此锁尝试。默认变化明确局限于 Windows 争用后的 EPERM；未激活分支、其它目标、零等待及失败清理均有反例。无需新配置或前端开关，既有调用者直接获得同一锁 owner 的恢复。future-facing pass 考虑了共享重试 helper，但它会掩盖本地 opened/contended 约束；保留短条件与原 cleanup owner 更容易定位、验证和回滚。

我的整体评价

APPROVE 有界恢复与 fixture 清理修复。当前证据能区分真正改变的分支、范围外错误和旧清理缺陷。没有发现待归因的新回归；原生 Windows、间歇故障根因与长期资格没有被升级成已通过。质量回执和独立合并资格继续由各自 owner 处理，本次不合并。

English verdict: APPROVE — ef46fdc835522978be214d9e3517c2eb66b63262 bounds Windows post-contention open retries and reuses exact-process cleanup. Identical filesystem tests fail2/pass13 on base and pass15 on head;93 lifecycle tests pass. The old-cleanup counterfactual starts an extra retired runtime. Native Windows/root-cause qualification and the local missing quality receipt remain separate.